# monitor.incidents
Finds the incidents in a stored series of checks (`monitor.check-status`'s
`Check`): each run of consecutive bad checks is one incident.
## Rules
- **Bad** depends on `incidentStatus`: with `down`, only `down` checks are
bad (a slow site is not an outage); with `degraded`, `degraded` and `down`
both are, and one incident can mix them. `up` is refused: an "incident of
being up" is a configuration mistake.
- A run counts only when it has at least `confirmChecks` checks. This is flap
suppression, the same idea as "alert after N consecutive failures" in most
uptime monitors: one lost probe does not make an outage, and would drag
MTTR down if it did. Shorter runs are dropped entirely, including an
unconfirmed run still in progress at the last check.
- `start` is the `at` of the first bad check; `end` is the `at` of the first
check after the run that is not bad (with `incidentStatus: down`, a
`degraded` check ends a down incident). An incident still bad at the last
check is ongoing: `end` is null and `durationSeconds` runs to `now`.
- The start is the first check that *saw* the failure, not a guess at when
it really began between two checks; and the end is the first check that saw
recovery. So durations are accurate to the check interval, and err long.
- `worst` is `down` if any check in the run was down, else `degraded`.
- `checks` counts the bad checks in the run.
Incidents come out in time order and never overlap, which is what
`monitor.mttr` expects.
## Errors
- `checks must be in strictly ascending time order`
- `unknown check status: X`
- `incidentStatus must be down or degraded, received up`
- `confirmChecks must be at least 1`
- `now 200 is before the last check at 240`: now ends ongoing incidents, so it
cannot be earlier than the data.
- `now must be a whole number of seconds`