Incidents, acknowledgement and alert noise control

An incident is CompleteStatus's record of a confirmed outage: when it started, why, everything that happened while it was open, and when it ended. This guide covers the incident lifecycle, the timeline, postmortems, and the tools that keep repeat notifications under control.

When an incident opens

CompleteStatus never opens an incident on a single failed check. The rule is:

1. A check fails once — the monitor stays Up (the failure is unconfirmed).
2. A second consecutive check fails — the monitor transitions to Down, an incident opens, and down alerts fan out to the monitor's enabled alert rules.

The incident's cause is captured from the failing check: the error message when there is one, otherwise the HTTP status (for example HTTP 500), or "Check failed".

While the monitor stays down, further failed checks do not open new incidents — each one is appended to the open incident's timeline instead, so you keep a single record per outage.

Note: Paused monitors and monitors in maintenance status never open incidents; check results are still recorded but the state machine leaves them alone.

Incident states

An incident moves through three states:

• Open — down and nobody has claimed it yet.
• Acknowledged — a team member pressed Acknowledge; still unresolved, but claimed. The acknowledger's name and time are stamped on the timeline.
• Resolved — the outage is over.

Resolution happens two ways:

• Automatically — the first successful check after a confirmed down flips the monitor back to Up, resolves the open incident, records the total downtime in seconds on the timeline, and fans out up (recovery) alerts.
• Manually — press Resolve on the incident page. Use this for incidents that no longer apply (for example a deleted endpoint).

Acknowledging an already-resolved incident is a no-op, and resolving twice does nothing.

Browsing incidents

The incident list at /incidents shows all incidents across the current organization's monitors, 20 per page, newest first. You can filter by:

• Status — open, acknowledged, or resolved (the list defaults to open).
• Monitor — a single monitor.
• Date range — opened-at from/to dates.

Filters persist across pagination.

The incident detail page

Open any incident to see:

• Header — the monitor, cause, opened / acknowledged / resolved timestamps, and the Acknowledge / Resolve buttons for the states that still apply.
• Timeline — every event in chronological order: opened (with the failing check's status code and how many consecutive failures confirmed it), check_failed entries for each further failure while down, acknowledged (with the user's name), latency_anomaly entries when the anomaly detector flags a p95 spike during the outage, and resolved (with downtime in seconds for auto-resolutions).
• Diagnostics — automatically captured failure forensics: the failing check's exact error and timing phases, a snapshot of the response headers and body, and (on Business+) a traceroute to the target. Full guide: Incident forensics.
• Screenshot — for web monitors on Pro and above, CompleteStatus automatically captures a screenshot of the failing page when the incident opens, so you can see what users saw.
• Postmortem — a free-text write-up you can save on the incident after the fact. Saving an empty postmortem clears it. For a structure worth copying, see Blameless postmortems for small teams.

Note: There is no separate comment thread on incidents — the timeline is system-generated, and the postmortem field is the place for human write-ups.

Repeat notifications and escalation

CompleteStatus does not have multi-step escalation policies (no "notify X, then Y after 15 minutes" chains). What it does have:

• Event routing — each alert rule on a monitor picks which channel gets which events (down, up, and others). Route down to your pager-style channel and up to a quieter one if you like. See /docs/alert-channels.
• Per-rule cooldown — each rule has a cooldown of 0–1440 minutes. A channel that already received an alert for the monitor within the cooldown is skipped, which stops a flapping monitor from paging you every few minutes.
• Deduplication — each incident event is delivered at most once per channel, even if delivery jobs are retried. Failed sends retry automatically with backoff (10 s, 60 s, 5 min).

There are no scheduled reminder re-alerts for incidents that stay open; you get one down notification per channel per incident (subject to cooldown) and one up on recovery.

Muting alerts

Two tools silence notifications without losing data:

1. Maintenance windows — scheduled or ad-hoc periods during which all alert fan-out for covered monitors is suppressed. Incidents still open and record normally; you just don't get paged. The maintenance page also has one-click Mute for 30 min / Mute for 60 min buttons for deploys. Full guide: /docs/maintenance-windows.
2. Pausing a monitor — the pause button on the monitor page stops checks entirely (status becomes Paused, no checks, no incidents) until you resume it.

Warning: Pausing stops monitoring altogether — you will not know if the service breaks while paused. For planned work where you still want history recorded, prefer a maintenance window.

Related guides

• /docs/alert-channels — channels, alert rules and cooldowns.
• /docs/incident-forensics — the diagnostic evidence captured when an incident opens.
• /docs/maintenance-windows — planned-work muting in depth.
• /docs/status-pages — how incidents appear to the public.

Further reading: Alert fatigue — how teams learn to ignore their own alarms and MTTD, MTTA, MTTR, MTBF explained on the blog.