An incident is either Active or Resolved. The state describes the retained incident record; it is separate from whether an email or SMS was delivered.
Active availability incident
An availability incident becomes Active when the monitor changes to Down after:
- A primary check fails.
- At least two of three monitoring regions confirm failure for the cycle.
- Three confirmed failed cycles occur consecutively.
The incident start time is the check that completes the confirmed Down transition. Earlier failed rows remain in Detailed Logs but are not added to the incident duration before confirmation.
While the incident is Active, later failed checks add evidence but do not create a new incident for every interval.
Resolved availability incident
After a monitor is Down, one effective successful availability cycle changes the monitor to Up and resolves the Active incident.
The resolved record stores:
- Recovery time.
- Duration from the confirmed incident start to recovery.
- Last available response details.
- Recovery activity and eligible notification records.
If another confirmed outage happens later, Uptime Basics creates a separate incident rather than reopening the resolved record.
Active performance incident
A performance incident can become Active when Slow Response Alerts are enabled and the configured number of consecutive successful checks exceed the response-time threshold.
The monitor can remain Up because the website is reachable. The incident records sustained performance degradation rather than an availability outage.
Resolved performance incident
A performance incident resolves after the configured number of later successful checks no longer meet the slow-response condition. Its duration tracks the performance-warning period.
An availability failure is handled by the availability system; it is not counted as a healthy performance response.
Pausing during an Active incident
Pausing stops future scheduled checks. The existing incident remains Active because no new result can prove recovery while monitoring is paused.
After reactivation, the next eligible results can update the monitor and resolve the incident. The duration can therefore include time when the monitor was paused.
Alerts do not control incident state
An incident can open or resolve even when:
- Email or SMS is disabled.
- A destination is not verified.
- A notification fails, bounces, or is suppressed.
- Delivery occurs later than the monitoring event.
Use the incident timestamps for the monitoring timeline and Alert History for the notification timeline.
Data available after resolution
Incident history remains for the life of the monitor. Alert History and raw checks have shorter retention periods, so an older resolved incident can remain after some nearby delivery and check records have expired.
Archiving, pausing, or placing a monitor in Recently deleted preserves the incident record while applicable retention continues. Permanent monitor cleanup queues incidents and related monitoring data for removal.