Linking incident.io as a source
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.
The incident.io connector syncs your incident management data – incidents, alerts, escalations, follow-ups, users, schedules, and configuration – into PostHog.
Adding a data source
- Go to the sources tab of the data pipeline section in PostHog.
- Click + New source and then click Link next to incident.io.
- Create an API key in your incident.io dashboard. API keys have per-resource permissions – grant the
viewscope for each resource you want to sync (incidents, follow-ups, alerts, users, and so on). - Back in PostHog, paste your API key and click Next.
- 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 | — | — |