An incident is a retained record of a confirmed availability outage or performance problem. It is created only after the relevant confirmation rules are met, not for every unusual check.
Uptime Basics currently records two customer incident types: availability and performance.
Availability incidents
An availability incident opens when an active monitor changes from Unknown or Up to Down.
For that change to happen:
- The primary availability request fails.
- The failure is evaluated from additional monitoring regions.
- At least two of three regions report failure for that check cycle.
- Three region-confirmed failed check cycles occur consecutively.
The incident starts at the check that causes the confirmed Down transition. Earlier failed checks remain visible in Detailed Logs, but they are not added to the incident duration before the outage is confirmed.
This distinction reduces alerts caused by one temporary routing, DNS, timeout, or server problem.
Performance incidents
A performance incident can open when Slow Response Alerts are enabled and successful responses meet or exceed the selected response-time threshold for the selected number of consecutive checks.
Performance incidents:
- Track a slow but reachable website.
- Do not change the availability status from Up to Down.
- Use the slow-response threshold and confirmation count saved on that monitor.
- Resolve after enough later checks no longer meet the slow-response condition.
SSL expiry warnings and domain-expiry warnings are alerts, not availability or performance incidents.
What does not create an availability incident
An availability incident does not open solely because:
- One row in Detailed Logs is Down.
- One monitoring region cannot reach the target.
- A successful response exceeds the slow-response threshold.
- An SSL certificate or domain is approaching expiry.
- A monitor is paused, archived, or waiting for its first result.
- An alert message fails to deliver.
Failed checks remain useful even when they do not create an incident. They can reveal intermittent network, DNS, TLS, status-code, or latency patterns.
What the incident records
An availability incident record includes the monitor, confirmed start time, open or resolved state, first failure details, response timing, and regional confirmation evidence. When available, the incident page can also show:
- Failure Diagnosis and a recommended action.
- DNS, TCP, TLS, and HTTP diagnostic summaries.
- Checks around the incident.
- Alert and recovery activity.
- The recovery result and total incident duration.
Diagnostics are requested when an availability incident opens, subject to service-protection and diagnostic cooldown rules. The incident still opens when a diagnostic run is unavailable or intentionally limited.
How an availability incident resolves
After a monitor is Down, one successful effective availability result changes it to Up and resolves the open availability incident. A primary-region failure that is not supported by enough regional failures can also provide evidence that the website is reachable and prevent or resolve a false regional outage.
The incident duration is measured from the confirmed Down transition to the recovery transition. Alert delivery can happen after those timestamps because notifications are processed separately.
If a monitor is paused while an incident is open, no future check can confirm recovery until the monitor is activated again.
How long incidents remain
Incident history remains available for the life of the monitor. Raw checks and alert-delivery records have shorter retention periods, so an older incident can remain after some of its surrounding raw records have expired.
Deleting the monitor preserves its incidents during the 30-day recovery period. Permanent cleanup sends the incidents and related monitoring history through background cleanup.