Skip to main content
Sync your incidents, follow-ups, actions, alerts, and escalations into a data warehouse to report on them alongside your other data, like joining follow-ups to Jira tickets or incidents to revenue. There are three ways to do it:
  • Fivetran: a managed connector, with nothing to run yourself.
  • Singer tap: our open-source exporter, which you run on your own infrastructure.
  • Your own pipeline: read the API directly, when you want incremental syncs or control over exactly what you load.
Whichever you choose, How incident.io measures incidents explains what each timestamp and duration means, and which incidents are counted.

Fivetran

Fivetran’s incident.io connector loads your incident.io data into any Fivetran destination. It re-imports every table on each sync, so it picks up changes and deletions without any extra setup. Create an API key for it, and follow Fivetran’s setup guide.

Singer tap

Our Singer tap exports your incident.io data to any Singer target, including BigQuery, Snowflake, and Redshift. You run it yourself, on a schedule or from CI, and it exports everything on each run. See the tap’s documentation for configuration.

Build your own pipeline

What to sync

Each of these list endpoints supports an updated_at filter, so after an initial import you only fetch what changed: Use an API key with the View data permission. Add the View all incident data permission to include private incidents.

Initial import

Page through each endpoint with the largest page_size it allows:
Pass the after value from pagination_meta to fetch the next page. Stop when a page returns fewer records than your page_size. Don’t wait for after to disappear, because the incidents endpoint can return an after value on its last page.

Incremental syncs

From then on, fetch only what changed since your last sync:
  • Treat every row as an upsert, keyed on id. An incremental sync can return records you’ve already loaded.
  • Filter by the day of your last sync, not the time. The incidents and escalations endpoints take a date, so updated_at[gte]=2026-10-01 returns everything updated since the start of that day. Follow-ups, actions, and alerts also accept a full timestamp. Set it a few minutes before your last sync, so you don’t miss a record that was being written as it ran.
  • Run an occasional full re-sync to catch anything an incremental window missed.
Listing incidents is limited to 60 requests a minute, lower than the rest of the API. At 250 incidents a page, that’s still 15,000 incidents a minute. See rate limits.

Which incidents are included

The incidents endpoint leaves out test and tutorial incidents by default, along with incidents that were declined, canceled, or merged. To load those as well, filter on them explicitly with mode and status_category. See Which incidents are counted.

React to changes as they happen

If you need changes in your warehouse within seconds rather than on a schedule, subscribe to webhooks. When one arrives, fetch the record’s latest state from the API and upsert it, since webhooks can arrive out of order.