> ## 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 PostHog as an alert source

> Turn PostHog error tracking issues into pages and incidents in incident.io.

PostHog's error tracking groups exceptions into issues and can notify you when an issue is created, reopened, or starts spiking. Connect it to incident.io to page the right people when that happens.

PostHog sends alerts to incident.io through an HTTP webhook. Each trigger has its own webhook, so you create one for each trigger you want, all pointing at the same incident.io alert source. Alerts take their title from the exception, describe which trigger fired, and link back to the issue in PostHog when you include the project in the webhook body.

## 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 **PostHog** and click **Continue** to create the alert source.

5. In PostHog, open **Error tracking → Configuration → Alerting** and click **New notification**.

6. Choose the **HTTP Webhook** for the trigger you want: issue created, issue reopened, or issue spiking.

7. Paste the **Webhook URL** from the incident.io setup page into the webhook URL field.

8. Under **Headers**, add an `Authorization` header set to `Bearer {secret_token}` using the token shown in incident.io.

9. Replace the JSON body with this template, so alerts link back to the issue in PostHog:

   ```json theme={null}
   {
     "event": "{event}",
     "project": {
       "id": "{project.id}",
       "name": "{project.name}",
       "url": "{project.url}"
     }
   }
   ```

10. Click **Test function**, then **Create & enable**. If it's set up correctly, the alert appears in incident.io.

Repeat steps 5 to 10 for each trigger you want alerts for, using the same URL and token each time.

## What each PostHog event does

| PostHog event                                                       | What incident.io does                             |
| ------------------------------------------------------------------- | ------------------------------------------------- |
| `$error_tracking_issue_created`                                     | Opens an alert for the issue                      |
| `$error_tracking_issue_reopened`                                    | Reuses the issue's open alert, or opens a new one |
| `$error_tracking_issue_spiking`                                     | Opens a separate alert for each spike             |
| `$error_tracking_issue_resolved`                                    | Resolves the issue's alert                        |
| `$error_tracking_issue_suppressed`                                  | Resolves the issue's alert                        |
| `_assigned`, `_unassigned`, `_merged`, `_split`, or any other event | Accepted, and no alert is opened or resolved      |

Created and reopened share one alert per issue, so you're paged once per issue however many alert rules match it. Each spike gets its own alert, because PostHog has already aggregated the exceptions into it and a spike on a known issue needs its own page.

## Resolve alerts automatically

Send the `$error_tracking_issue_resolved` event to the same webhook URL and incident.io resolves the issue's alert when someone resolves it in PostHog. PostHog's Alerting page has no ready-made webhook for it, so create one more HTTP Webhook from any of the three, and set its **Trigger** to **Error tracking issue resolved**.

Resolving the alert doesn't resolve an incident on its own. For triage incidents, turn on **Decline triage incidents if the linked alerts are resolved** on the alert route. For live incidents, trigger a [workflow](/workflows/getting-started) on alert resolution. Spike alerts are separate alerts, so resolve those in incident.io.

## Route alerts by team

PostHog issue events don't name an owning team, so add one to the JSON body yourself, for example `"team": "payments"`, and read it into a Team [alert attribute](/alerts/attributes-and-priorities) with the expression `$.team`. If you use PostHog's assignment rules, filter each webhook by assignee and create one webhook per team instead. 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.