How incidents open and close

An incident is UpAll's record that a monitored system was down — when it started, when it ended, and what the checks saw in between. For automated checks, the whole lifecycle runs without anyone touching the console: opening, timing, resolving, and notifying are all automatic.

Opening: consecutive failures, not one

Every monitor has a Failures before incident setting (1–10, default 3). UpAll opens an incident only when that many checks fail in a row. A single failed check is often noise — a dropped packet, a brief spike, a server's busy moment — and treating each one as an outage would bury your team in false alarms; see false positives and flapping.

With the defaults (checks every minute, 3 failures), a real outage becomes an incident about three minutes after it begins. If a monitor guards something critical enough that speed beats caution, lower the setting; the trade-offs are covered in check intervals and thresholds.

Incidents opened by checks always carry the Outage severity — automation doesn't guess at nuance. The other severities and their sources are in incident severities.

The start time is backdated

The incident's start time is the first failure of the streak, not the moment the threshold was crossed. The outage began when the target stopped answering; the confirmation delay is UpAll being careful, and that caution shouldn't erase minutes from the record. This is what keeps downtime minutes, "resolved in N minutes", and SLA math honest.

Closing: the next OK check

The incident resolves automatically on the very next successful check. There is no acknowledgment step and nothing to close by hand — when the target answers again, the incident gets its resolution time and the downtime duration is fixed. If the target then fails for another consecutive streak, that's a new incident with its own timeline, which is exactly what a flapping service should look like in the record.

What your team is emailed

Both events trigger email — one message when the incident opens, another when it resolves. Every active staff member (admins and engineers) receives it, each in their own language, with the client, the monitor, the site, the start time in the workspace timezone, the last recorded error, and a link to the incident. Details in email alerts.

What automation can't see

Automatic incidents only cover what checks observe. For outages that need human context — an upstream provider failure, planned work, an explanation your client should read — staff can write manual incidents with any severity and their own timestamps.