Incidents
How Obzerv detects, verifies, and resolves outages.
An incident records a confirmed outage. A failed regional probe alone does not necessarily mean the service is globally Down.
Lifecycle
- Observation — deployed workers check the target independently.
- Confirmation — the configured quorum of fresh failed regional observations opens an incident. Global checks keep their configured quorum when a worker disappears; deliberately selected single-region monitors use that region alone.
- Open — the incident remains open until a reliable recovery verdict arrives.
- Recovery — a fresh successful target check can resolve the incident when the consensus store is available and fresh Down votes no longer meet the quorum. Recovery does not require every region to vote Up.
Infrastructure failures and inconclusive probes neither start outages nor manufacture recoveries. The last confirmed state is retained, with unknown or stale data shown separately. Missing observations alone cannot close an incident.
What's in an incident
| Field | What it means |
|---|---|
started_at | Timestamp of the first verified failed check. |
resolved_at | Timestamp of recovery, or null if still open. |
cause | Confirmed target failure (e.g. HTTP 502, dial tcp i/o timeout, dns no such host). |
monitors | Embedded { name, url } snapshot of the monitor — saves you a second lookup. |
Notifications
When an incident is opened or resolved, every enabled notification channel subscribed to the monitor receives a payload. See webhook events for the full schema.
Maintenance windows
If a planned maintenance window covers the incident's start time, the incident is still recorded but notifications are suppressed. This lets you keep an honest history without paging on expected downtime. Pro plan and above — see the API reference.