> ## Documentation Index
> Fetch the complete documentation index at: https://docs.incident.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Adding Logz.io as an alert source

> Turn Logz.io log alerts into pages and incidents in incident.io.

Logz.io monitors your logs and metrics and can notify you when an alert definition breaches. Connect it to incident.io to page the right people when that happens.

Logz.io has no native incident.io notification channel, so you point a **Custom** notification endpoint at incident.io and paste in the JSON body template from your alert source setup page. That template maps Logz.io's [alert placeholders](https://docs.logz.io/docs/user-guide/integrations/notification-endpoints/custom-endpoints/) onto the fields we expect. Severity, tags, alert definition, and account land in the alert payload's `metadata` field, so you can use them to power [alert attributes](/alerts/attributes-and-priorities) and routing.

## Instructions

1. Head over to the [Alerts](https://app.incident.io/~/on-call/alert-routes/sources) section in your incident.io dashboard.

2. Select the **Sources** tab at the top of the page.

3. Press the **Create source** button.

4. Search for **Logz.io** and click **Continue** to create the alert source.

5. In Logz.io, go to **Settings → Notification endpoints** and add a new **Custom** endpoint.

6. Set the method to **POST** and paste in the URL from the incident.io setup page. Under **Headers**, add an `Authorization` header set to `Bearer {secret_token}` using the token shown in incident.io.

7. Paste the JSON body from the incident.io setup page into the endpoint's **Body**. It maps Logz.io placeholders onto the fields we expect.

8. Assign the endpoint to your alert definitions, then use **Test** on the endpoint to send a sample alert. If it's set up correctly, the alert appears in incident.io.

<Warning>
  Logz.io only notifies incident.io when an alert triggers, not when it stops firing, so alerts will not resolve on their own. Turn on **auto-resolve** for this source so they close after a set time, or resolve them by hand once handled.
</Warning>

<Tip>
  You can append query parameters to the webhook URL (e.g. `?team=backend`) to route or enrich alerts without changing the alert definition. They're available in attribute expressions under `query_params`.
</Tip>

## Route alerts by team

Logz.io tags are free-form strings. The recommended approach is to add a tag on each alert definition that names the relevant team or service, for example `team:platform`, and parse it out of the comma-separated `metadata.tags` string into a Team [alert attribute](/alerts/attributes-and-priorities).

Alternatively, create one custom endpoint per team, append a query parameter such as `?team=platform` to each URL, and read it with `$['query_params']['team']`. See [routing alerts to teams](/alerts/team-routing) for what to do with the attribute once it's set.

Once alerts are arriving, [create an alert route](/alerts/getting-started) to filter, group, and escalate them, or to automatically create incidents.
