Incidents

An incident is a fired alert that's been routed to a channel. The Incidents page is where the on-call lives during a problem.

The list

Five filter tabs: All | Open | Investigating | Mitigated | Resolved.

Columns:

  • Title — incident summary, click to open detail.
  • Severity — color pill: red (Critical), amber (Warning), blue (Info).
  • Status — current lifecycle state.
  • Group labels — what tied alerts together. Common: service=payments, cluster=prod.
  • Acknowledged — who acked, with a clock icon if their ack expired.
  • Alerts — number of underlying alert events grouped into this incident.
  • Created — when the first alert in the group fired.

Lifecycle states

  • Open — incident is firing. Notifications going out per the routing policy's renotify schedule.
  • Investigating — someone's looking. Notifications still go out (unless silenced).
  • Mitigated — workaround applied, root cause not fixed yet. Notifications stop. The incident reopens automatically if the underlying alert fires again.
  • Resolved — fully done. Notifications stop. Reopens only if the alert fires again within the routing policy's reopen window.

Acknowledging

Click an incident → Acknowledge in the detail page. Optionally add a comment ("looking into it", "investigating database").

Ack does three things:

  1. Moves the status from Open to Investigating (if it was Open) and records who acknowledged and when.
  2. Stops renotification until the ack timeout elapses (default 30 minutes, or the routing policy's ack-timeout). After that the ack expires and renotification resumes — useful if the engineer walks away from a long incident.
  3. Stamps your name + comment on the timeline.

Reopen behavior

If an alert resolves and then fires again within the routing policy's reopen window (default 120 minutes), the existing incident reopens with reopened_count incremented. Beyond the window, a fresh incident is created.

This avoids a flapping alert creating dozens of incidents.

Detail page

Each incident's detail page has:

  • Header: title, severity, status, action buttons.
  • Group labels: as a label=value pill stack.
  • Routed to: the policy name that matched, with channels.
  • Ack history: who acked, when, comment. Includes ack expiries.
  • Timeline: every alert event (firing, resolved, reopened) with timestamps and values.
  • Notification log: every dispatch attempt — channel, status (success / retry / failed / suppressed), and reason if suppressed.
  • Open in Logs: deep-link into the log explorer scoped to the alert's source and time range.

Bulk actions

Checkboxes on the list let you bulk-acknowledge, bulk-mitigate, or bulk-resolve. Useful when a deploy creates a swarm of related incidents you want to clear at once.

What incidents are *not*

  • Incidents are not tickets. They're a runtime state. If you need a ticket, integrate with Jira or ServiceNow via a webhook channel that creates one on incident open.
  • Incidents are not chat threads. Use the deep-link to take the conversation to your incident-management Slack/Teams channel.
  • Incidents are not post-mortems. Resolving an incident doesn't capture root cause. Track that in your usual post-mortem flow.

See also

The Incidents page covers the list UI, filters/search, bulk actions, and manually opening an incident (+ New Incident).