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.
Contents
This source is currently in alpha. The interface and available tables may change.
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 | — | — |