incidents

An incident is the record of something was off until it wasn't. It captures a continuous stretch of trouble as one event, even if the monitor bounced between degraded and down along the way.

open and close

An incident opens when a monitor enters degraded or down and no incident is already open. That covers up → degraded / up → down in steady state, and also pending → degraded / pending → down for a monitor that's broken from its very first check.
It closes on any transition back to up.

The decision keys on is an incident already open?, not was the monitor up before? — so a monitor that was never healthy still gets exactly one incident, not a new one per failed check.

severity

Every incident carries a severity that tracks the monitor's current state:

warning — the incident is currently at degraded.
critical — the incident is currently at (or has touched) down.

When a monitor moves between degraded and down without recovering to up in between, the open incident's severity updates in place — it does not open a new incident:

degraded → down escalates the incident warning → critical.
down → degraded de-escalates it critical → warning.

note

The incident keeps a high-water mark. Once an incident has touched critical, a brief de-escalation back to warning can't make it look like a minor blip in hindsight — reporting still reflects the worst it reached.

This matches how people actually describe an outage: "the cert started warning a week ago, went critical yesterday, fixed today" is one event with two phases — not three separate incidents.

the phase timeline

The detail page renders an incident as a phase timeline: a proportional severity bar plus an event log. Each lifecycle step — opened, transition, resolved — is stored as its own event stamping the from/to severity and the failure reasons at that moment, and the timeline shows the duration split between degraded and down.

This history lives in its own store, separate from raw check results. Check results are pruned after 90 days, but incidents are kept indefinitely — so the timeline survives even for incidents far older than the check-retention window.

browsing incidents

The /incidents page lists incidents across the org with filter chips — active (the default: critical + warning), critical, warning, and resolved — each with a count. Active rows are tinted by their current severity and pulse; resolved rows are tinted by the high-water severity they reached and sit muted. Each monitor's detail page has an incidents tab scoped to just that monitor.

uptime accounting

Incident time at down reduces uptime %. Incident time at degraded does not — the site was reachable, so it counts as uptime. See monitor states.

previousmonitor states nextnotification channels