Incidents

An incident is opened every time a monitor is confirmed down, and resolved automatically when it recovers. Incidents are the history of your outages: when they started, how long they lasted, what failed and who reacted.

Lifecycle#

1. Opened — the failure is confirmed (two regions, or two consecutive checks from a single region; see Monitors). The monitor turns Down.
2. Notified — each contact in the monitor's alert rules is alerted after its delay, then reminded at its repeat interval.
3. Acknowledged (optional) — someone on the team confirms they are on it. Reminders stop.
4. Resolved — the monitor is up again. Contacts that got the down alert receive a recovery alert with the downtime.

Each step is recorded in the incident's timeline (opened, notified, acknowledged, comment, resolved) with its time.

The incident page#

Open Incidents to see open incidents (or all of them), filter by monitor, and open one for details:

• Cause — what failed, as reported by the checker: Timeout, HTTP 503, a DNS or TLS error… Causes are technical texts and are not translated.
• Regions — the regions that saw the failure.
• Duration — so far, or in total once resolved.
• Snapshot of the first failing check: status code, response time, error kind and detail and — for HTTP checks — up to 20 response headers (cookies are never stored).
• Timeline and comments.

Acknowledging#

Press Acknowledge on an open incident to tell your team you are handling it. Acknowledging:

• stops all reminders for this incident (the repeatEveryMinutes of every alert rule);
• is recorded in the timeline with who acknowledged it and when;
• does not resolve the incident — only a successful check does that.

You can also acknowledge with the API (POST /incidents/{id}/acknowledge). (The Acknowledge button on the mobile app's alarm screen only silences the alarm on that phone.)

Comments#

Add comments to an incident to keep notes for the team: what you found, what you changed, a link to the post-mortem. Comments appear in the timeline. Incident comments are available on plans that include them — see Pricing.

Incidents and status pages#

Status pages show active incidents of the monitors they include, plus the incidents of the last 14 days, and their daily bars reflect the downtime. Subscribers of a page are e-mailed when one of its components goes down and when it recovers. See Status pages.

Reducing noise#

• Use several regions for important monitors: a failure must then be seen from two places.
• Add a delay ("After") to alert rules for less critical contacts, so short blips resolve before anyone is paged.
• Schedule maintenance windows for planned work: monitors in a window don't open incidents or alert. See Maintenance windows.
• Tune timeouts and accepted status codes on HTTP monitors that are legitimately slow or redirect.