How incidents work
The lifecycle of a problem — from a confirmed failure to resolution.
An incident is the story of one problem, from the moment it's confirmed until it's resolved. It keeps everything about that problem in one place: what failed, when, who was notified, and what your team did.
Confirmation — why one blip won't page you
When an alert rule matches, WatchFor doesn't open an incident immediately. It confirms the failure across multiple locations first. If only one location sees the problem, it's likely a local network issue — not your service — and no incident opens.
This is why a monitor can show Degraded (a check failed) without being Down (a confirmed incident). It keeps your alerts trustworthy.
The lifecycle
firing → acknowledged → resolvedFiring
The problem is confirmed and active. Notifications have gone out.
Acknowledged
Someone on the team has taken ownership — useful so others know it's being handled.
Resolved
The condition recovered (or someone resolved it). A recovery notification is sent.
What's on an incident
- A root-cause breakdown — the failing condition, the probe results that confirmed it, and the rule in effect.
- A timeline of everything that happened, including who acknowledged or resolved it and why.
- Internal notes for your team — private, never shown publicly.
Faster checks during an incident
While an incident is active, WatchFor can check more often so you see recovery the moment it happens, then return to the normal cadence afterwards.
Grouping and noise control
Related failures are correlated so a single underlying problem doesn't become a storm of separate alerts. See Resolving incidents for how incidents close — automatically and manually.