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:
- Moves the status from Open to Investigating (if it was Open) and records who acknowledged and when.
- 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.
- 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).