Incidents

An incident is a tracked event with a lifecycle (investigating → identified → monitoring → resolved), a severity level, and a timeline of updates. Incidents can be created manually or auto-opened by alert rules when a monitor goes down.

Incidents are independent of status pages — you can use them as an internal-only record of outages without ever publishing them. When you do link an incident to a status page, updates push to subscribers automatically.

Find them in the WebUI at Incidents.

Lifecycle

Status	Meaning
investigating	Initial state. Something is wrong, you’re looking.
identified	You’ve found the cause.
monitoring	The fix is rolled out, watching to confirm.
resolved	Confirmed fixed. Closes the incident.

A monitor recovering on its own doesn’t auto-close incidents; the person closing the incident is also asserting “I checked, it’s genuinely fixed” — different signal from “checks went green”.

Severity

Severity	Use it for
critical	Full outage, customer-impacting, page everyone.
major	Significant degradation, page on-call.
minor	Edge-case failure, daylight-hours fix.
maintenance	Planned work. Use maintenance windows instead unless you want this on the status page banner.

Severity feeds the visual treatment on linked status pages and the default colour in alert messages. Pick one when you open the incident; you can change it later.

Auto-create from alerts

Alert rules can be configured to open an incident automatically when they fire. The auto-created incident:

• Starts in investigating with the severity you configured on the rule (defaults to major).
• Links to the monitor that triggered the alert.
• Optionally links to a status page so the outage shows up on the public page from minute zero.

The matching auto-resolve setting closes the incident when the underlying monitor recovers — handy for short outages where nobody ever logged in to mark it resolved manually.

Timeline updates

Each incident has an append-only timeline. Post an update with:

• Status change — bump status to identified, monitoring, etc.
• Message — free-text note. Markdown supported on status pages.

Updates push to subscribers on any linked status page within seconds.

Linking

An incident can link to:

• Monitors — typically the monitor(s) that triggered the incident. Linked monitors show up on the incident page so the on-call has the latest check data without flipping tabs.
• Monitor groups — same effect for a whole group.
• Status pages — published on the linked page’s banner + history. Multiple status pages OK if a single outage affects more than one product surface.

Links can be added or removed at any point during the incident, not just at create time.

Acknowledgement vs resolution

These are different things:

• Acknowledge lives on the alert rule (the Active Alerts panel on /alerts). Stops further paging. Doesn’t close the incident.
• Resolve closes the incident. Pushes a final update to status page subscribers.

Acknowledge to stop the noise; resolve when the fix is verified.

Hidden incidents

Each incident has a “hidden from status page” toggle. Use it when you want an internal record but don’t want to publish — e.g. a brief blip you noticed before any customer would have, or a post-hoc tracking entry for a near-miss.

Hidden incidents still send alert-channel notifications; they just don’t appear on any linked status page.