The Root Cause and Regional Confirmation sections answer different questions:
- Root Cause classifies the best available failure evidence.
- Regional Confirmation shows whether the failure was reproduced from enough monitoring regions.
Neither section can see inside your hosting provider or application unless its public behavior reveals the problem.
Read the Root Cause summary
The summary starts with the diagnosis attached to a failed check. Common categories include:
| Summary | What monitoring observed |
|---|---|
| Authentication required | The URL returned HTTP 401. |
| Blocked | The site returned HTTP 403 to the monitoring request. |
| Method not allowed | The endpoint rejected the configured HTTP method. |
| Rate limited | The target returned HTTP 429. |
| Server error | The target returned a 5xx response. |
| Client error | The target returned another unaccepted 4xx response. |
| Timeout | The request did not finish before the configured timeout. |
| DNS | The hostname could not be resolved for the request. |
| SSL | The HTTPS certificate or TLS connection failed validation. |
| Redirect loop | Redirect handling could not reach a final acceptable target. |
| Unknown | The check failed without enough evidence for a more specific category. |
If no normalized category is available, the page can fall back to an error message, HTTP status, or Failed check.
Treat the summary as a diagnosis, not proof
For example, a timeout confirms that monitoring did not receive a response in time. It does not prove whether the cause was server load, a firewall, network routing, a stalled dependency, or another condition.
Use the recommended action as a first troubleshooting step. Compare it with hosting logs, application metrics, CDN or firewall events, DNS changes, and the detailed checks around the same time.
Understand the two-of-three regional policy
When the primary availability request fails, Uptime Basics can check from two additional regions. The current policy considers that cycle region-confirmed when at least two of the three regions report failure.
The page can list:
- Primary region: where the scheduled check began.
- Failed regions: monitoring locations that reproduced the failure.
- Healthy regions: locations that reached the target successfully.
- Attempted regions: locations requested for confirmation.
- Executed regions: locations that returned a usable confirmation result.
Three consecutive region-confirmed failed cycles are required before an availability incident opens.
Interpret common regional outcomes
Down confirmed from two or three regions suggests a broader problem than one isolated route, but it does not prove the site failed for every visitor worldwide.
Primary failure not confirmed; healthy in another region suggests a regional route, location-specific firewall rule, temporary primary failure, or short-lived issue. That cycle does not count as a confirmed failed cycle.
No regional confirmation data can occur for a performance incident, older record, unavailable confirmation run, or incident created before that evidence was stored. Do not treat missing evidence as either proof of uptime or proof of a global outage.
Regional evidence versus diagnostics
Regional checks repeat the availability request from other locations. Diagnostics inspect individual layers near the incident:
- DNS resolution.
- TCP connection.
- TLS negotiation and certificate details.
- HTTP response.
A site can fail regional confirmation while a later diagnostic run succeeds because conditions changed between the two operations. It can also pass from one region while diagnostics reveal a location-specific or intermittent problem.
Build a practical conclusion
- Confirm whether the incident is Active or Resolved.
- Read the Root Cause category and recommended action.
- Review failed and healthy regions.
- Compare DNS, TCP, TLS, and HTTP diagnostic cards.
- Expand Checks Around Incident.
- Compare the same period with your hosting, application, CDN, firewall, and DNS logs.
Describe conclusions in terms of observed evidence. For example, say "HTTP 403 was returned to two monitoring regions" rather than claiming a specific firewall rule caused the issue without checking its logs.