Incidents

How incidents open, group, resolve and reopen; acknowledging and assigning; and the audit trail every state change leaves.

An incident opens the moment a monitor trips its failure threshold, with flapping debounced so you get one page — not ten. A resolved issue that regresses reopens the same incident rather than duplicating it. Incidents can come from a downtime check, an anomaly episode, or an Intelligence signal; the source is on the incident.

Lifecycle

• Open — created automatically; the down (or incident_opened) event goes to destinations.
• Acknowledged — a person has seen it. POST /api/v1/incidents/{id}/acknowledge.
• Assigned — to a member of the organization.
• Resolved — automatically on recovery, or manually with POST /api/v1/incidents/{id}/resolve. The recovered event is sent.

Every transition is recorded with who and when, and the timeline on the incident interleaves the executions, the Intelligence events and any maintenance window that overlapped — so a post-incident review starts from one page.

Reading the timeline

Executions that failed keep the response status, timing and the assertion that failed; for HTTP monitors an excerpt of the body the assertion looked at is stored, so the incident shows what the API actually returned. Change events (a new certificate, a DNS answer that moved, a header that disappeared) that occurred shortly before the failure are shown alongside, which is usually where the cause is.

Maintenance windows are managed from Incidents → Maintenance windows; see Maintenance windows.