> AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt

# Linking incident.io as a source

Canonical URL: https://posthog.com/docs/data-pipelines/sources/incident-io

> **Cloud region:** This page uses US Cloud hosts. For an EU Cloud project, use `https://eu.posthog.com` instead of `https://app.posthog.com` (app host for links).

## On this page

- [Adding a data source](#adding-a-data-source)
- [Available tables](#available-tables)
- [Configuration](#configuration)
- [Supported tables](#supported-tables)

![](https://res.cloudinary.com/dmukukwp6/image/upload/texture_tan_9608fcca70)

![](https://res.cloudinary.com/dmukukwp6/image/upload/texture_tan_dark_a92b0e022d)

Let AI connect your sources for you

Skip the manual setup — run this in your project and the wizard auto-detects your databases and APIs and connects them to PostHog.

`npx @posthog/wizard warehouse`

![PostHog Wizard hedgehog](https://res.cloudinary.com/dmukukwp6/image/upload/wizard_3f8bb7a240.png)

![](https://res.cloudinary.com/dmukukwp6/image/upload/wizard_3f8bb7a240.png)Let AI connect your sources for you

The incident.io connector syncs your incident management data – incidents, alerts, escalations, follow-ups, users, schedules, and configuration – into PostHog.

## Adding a data source

1.  Go to the [sources tab](https://app.posthog.com/data-management/sources) of the data pipeline section in PostHog.
2.  Click **\+ New source** and then click **Link** next to incident.io.
3.  Create an API key in your [incident.io dashboard](https://app.incident.io/settings/api-keys). API keys have per-resource permissions – grant the `view` scope for each resource you want to sync (incidents, follow-ups, alerts, users, and so on).
4.  Back in PostHog, paste your API key and click **Next**.
5.  Select the tables you want to sync, set the sync method and frequency, then click **Import**.

Once the syncs are complete, you can start using incident.io data in PostHog.

## Available tables

| Table | Description | Sync method |
| --- | --- | --- |
| `incidents` | Incidents tracked in incident.io | Incremental |
| `incident_updates` | Updates posted to incidents | Full refresh |
| `follow_ups` | Follow-up action items from incidents | Full refresh |
| `alerts` | Alerts that triggered incidents | Full refresh |
| `escalations` | Escalation events | Full refresh |
| `users` | Users in your incident.io account | Full refresh |
| `schedules` | On-call schedules | Full refresh |
| `severities` | Severity levels configured in your account | Full refresh |
| `incident_roles` | Roles that can be assigned during incidents | Full refresh |
| `incident_statuses` | Status options for incidents | Full refresh |
| `incident_types` | Types of incidents configured | Full refresh |
| `custom_fields` | Custom fields configured in your account | Full refresh |

**Incremental** tables sync only new or updated records on each run. **Full refresh** tables reload all data on each sync.

Only the `incidents` table supports incremental sync because it's the only endpoint with both server-side timestamp filters and a sortable order. The remaining tables either lack timestamp filters or don't support sorting, so they use full refresh.

## Configuration

| Option | Type | Required |
| --- | --- | --- |
| `API key` | password | Yes |

## Supported tables

| Table | Description | Sync method | Incremental field | Primary key |
| --- | --- | --- | --- | --- |
| `incidents` | An incident tracked in incident.io, with its status, severity, and timeline. | Incremental, Full refresh | updated\_at, created\_at | — |
| `incident_updates` | A status update posted to the timeline of an incident in incident.io. | Full refresh | — | — |
| `follow_ups` | A follow-up action item created from an incident in incident.io. | Full refresh | — | — |
| `alerts` | An alert ingested into incident.io that may be attached to or trigger an incident. | Full refresh | — | — |
| `escalations` | An escalation in incident.io that pages on-call responders for an alert or incident. | Full refresh | — | — |
| `users` | A user in the incident.io organization. | Full refresh | — | — |
| `schedules` | An on-call schedule defining who is on-call and when in incident.io. | Full refresh | — | — |
| `severities` | A severity level that can be assigned to incidents in incident.io. | Full refresh | — | — |
| `incident_roles` | A role that can be assigned to responders during an incident in incident.io. | Full refresh | — | — |
| `incident_statuses` | A status an incident can be in within incident.io (e.g. triage, investigating, closed). | Full refresh | — | — |
| `incident_types` | A type that categorizes incidents in incident.io, controlling which custom fields apply. | Full refresh | — | — |
| `custom_fields` | A custom field that can be set on incidents in incident.io. | Full refresh | — | — |
| `custom_field_options` | An option that can be chosen for a single- or multi-select custom field in incident.io. | Full refresh | — | — |
| `incident_timestamps` | A named timestamp (e.g. impact started, reported, resolved) that incidents in incident.io can record. | Full refresh | — | — |
| `incident_alerts` | A link between an alert and the incident it is attached to in incident.io. | Full refresh | — | — |
| `catalog_types` | A type of entry in the incident.io catalog, such as services or teams, with the schema of its attributes. | Full refresh | — | — |
| `catalog_entries` | An entry in the incident.io catalog, such as a single service or team, with its attribute values. | Full refresh | — | — |
| `schedule_entries` | An on-call shift on an incident.io schedule after overrides are applied, covering a rolling window around the sync time. | Full refresh | — | — |
| `escalation_paths` | An escalation path in incident.io: the steps that describe how a page is escalated. | Full refresh | — | — |
| `alert_sources` | A source that sends alerts into incident.io, such as Datadog, Sentry, or an HTTP endpoint. | Full refresh | — | — |
| `status_pages` | A public or customer status page managed in incident.io. | Full refresh | — | — |
| `status_page_incidents` | A customer-facing incident published on an incident.io status page, with its updates. | Full refresh | — | — |
| `teams` | A team in the incident.io organisation, with its members and the catalog entry that represents it. | Full refresh | — | — |
| `actions` | An action item raised during the response to an incident in incident.io. | Incremental, Full refresh | updated\_at, created\_at | — |
| `incident_participant_workloads` | A participant of an incident in incident.io, with the role they had and the time they spent on it. | Full refresh | — | — |
| `alert_attributes` | An attribute defined on alerts in incident.io. The attributes of each alert reference it by ID. | Full refresh | — | — |