Skip to main content
Every incident metric in incident.io is built from two things: timestamps, which record when key moments in an incident happened, and duration metrics, which measure the time between two of them. This page defines both, explains which incidents are counted, and shows how they appear in the API. The same definitions apply in Insights, the API, and any tool that reads your incident data, like a data warehouse or an engineering metrics platform. You can configure timestamps and duration metrics in Settings → Response → Lifecycle, on the Timestamps and metrics tab.

Timestamps

Default timestamps

Your account starts with these timestamps. The statuses named are the defaults, so if you’ve renamed or replaced them, the rules follow your own statuses. An incident declared straight into an active status never passes through triage, so it has no Accepted at value.

Rules for custom timestamps

A timestamp you create is either set manually, or set automatically the first or last time an incident enters or leaves a status you choose. A “first” rule keeps its original value if the incident passes through the status again. A “last” rule moves forward each time.

Manual values take precedence

Once someone sets a timestamp by hand, in the dashboard or through the API, status changes won’t overwrite it. This is what lets a responder correct Declared at to when the incident really started, or fill in Impact started at after the fact.

Reopened incidents

Reopening an incident doesn’t clear any timestamps. When it’s resolved again, Resolved at moves to the new resolution time, and Closed at moves when it’s closed again. Timestamps with “first” rules keep their original values.

Imported incidents

When you create a retrospective incident, Declared at records when you ran the import, not when the incident happened. Set the timestamps you report on in incident_timestamp_values when you create each incident.

Duration metrics

A duration metric measures the time from one timestamp to another. New accounts start with three: Incident duration is the duration shown for each incident across the product. You can define as many other metrics as you need, between any two timestamps, such as Impact started at to Resolved at for a time to restore that starts when customers were first affected.

How a duration is calculated

  • The value is the time from start to end, in whole seconds.
  • Paused time is left out by default. To count the time an incident spent paused, edit the metric under Duration metrics on the Timestamps and metrics tab, and turn on Include paused time.
  • Both timestamps need a value. If either is missing, the incident has no value for that metric.
  • The end must come after the start. If it doesn’t, the incident has no value for that metric. Turn on Enable validation to stop responders saving timestamps in the wrong order. See Incident timestamps.
  • Values update when timestamps change. Editing a timestamp recalculates every metric that uses it, and changing which timestamps a metric uses recalculates it for every incident.

Which incidents are counted

Test and tutorial incidents are left out by default everywhere: in Insights and in the API. Declined, canceled, and merged incidents are left out by default too, because they weren’t real incidents or were counted under another incident. In Insights, you can include them from the filter bar. The Time spent and Follow-ups dashboards include them by default. Private incidents are left out of Insights by default. If your account has private incidents, turn on Include private incidents on a dashboard to add the ones you have access to. In the API, an API key only sees private incidents if it has the View all incident data permission. See API keys.

In Insights

Duration metric panels place each incident in your date range by its Declared at time, and report the median by default. You can also chart the mean and percentiles. Incidents with no value for the metric, or a value of zero, aren’t included. When you break a metric down by a multi-select custom field, an incident with several values counts once under each of them.

Linking incidents to services

Metrics by service or team come from custom fields on the incident. Use a Catalog-backed field, such as Affected services, so every incident points at the same service records as the rest of your tools. See Custom fields. For incidents created from alerts, an incident template can set these fields from the alert’s attributes. When you create an alert route, we suggest these for any custom field backed by the same Catalog type as one of your alert attributes.

In the API

The list incidents and show incident endpoints return both timestamps and durations on each incident. incident_timestamp_values lists every timestamp in your account, in order. Each entry has the timestamp’s id, name, and rank, and a value when the timestamp is set. A timestamp that isn’t set has no value. duration_metrics lists every duration metric, with the metric’s id and name, the value_seconds for this incident, and a status: Only use value_seconds when status is success. With other statuses, it may be missing or hold an earlier value.