Uptime Basics assigns a normalized diagnosis to a failed availability check. The category makes similar failures easier to filter even when the underlying error text differs.
A diagnosis is an informed classification based on the observed HTTP response or connection error. It is not a guaranteed root-cause determination.
Diagnosis reference
| Diagnosis | What was observed | Good next step |
|---|---|---|
| Blocked | HTTP 403; the site was reachable but rejected the monitoring request | Review firewall, CDN, WAF, bot, geo, and allowlist rules |
| Auth required | HTTP 401 | Use supported Basic Authentication or a public health endpoint |
| Method not allowed | HTTP 405 | If using HEAD, switch to GET; otherwise confirm the endpoint supports the request |
| Rate limited | HTTP 429 | Increase the interval or review rate-limit and allowlist rules |
| Content mismatch | The response did not contain configured expected text | Confirm the marker and monitored endpoint are correct |
| Connection refused | The destination actively rejected the TCP connection | Confirm the service is running, listening on the expected port, and allowed through the firewall or load balancer |
| Server error | HTTP 500 or higher | Review the application, origin, upstream services, and hosting provider |
| Client error | Another unaccepted HTTP 400-499 response | Confirm the URL, access requirements, and accepted-status configuration |
| Timeout | The request exceeded its timeout or was aborted | Review server load, timeout choice, network path, firewall, and CDN behavior |
| DNS | The hostname could not be resolved or DNS returned a temporary lookup failure | Review records, nameservers, domain registration, and DNS provider health |
| SSL/TLS | Certificate, hostname, chain, or TLS negotiation failed | Review certificate trust, expiry, hostnames, chain, and TLS configuration |
| Redirect loop | The redirect process failed or appeared to loop | Review HTTP/HTTPS, www/non-www, CDN, and origin redirect rules |
| Unknown | The failure did not match a more specific category | Use the Error, Confirmation, incident diagnostics, and site logs for context |
Diagnosis priority
When an HTTP response is available, specific status codes determine the category before general error text. For example:
- 401 becomes Auth required.
- 403 becomes Blocked.
- 405 becomes Method not allowed.
- 429 becomes Rate limited.
- 5xx becomes Server error.
- Other unaccepted 4xx responses become Client error.
Connection failures without an HTTP response are classified from the observed transport error, such as a refused connection, timeout, DNS, SSL/TLS, or redirect behavior.
Why a successful row has no diagnosis
Successful checks normally display a dash in Diagnosis because there is no failure to classify.
This also applies when you configure an otherwise failing HTTP status as acceptable. For example, an accepted 401 can count as Up and no longer receive an Auth required failure diagnosis. Only accept a status when it genuinely represents a healthy endpoint.
Diagnosis versus Confirmation
Diagnosis explains the type of one failed observation. Confirmation describes what happened when additional regions checked a possible outage.
These can produce combinations such as:
- Timeout diagnosis with other regions healthy: likely a localized or temporary failure.
- Blocked diagnosis across regions: likely a monitoring-access policy rather than a server outage.
- Server error confirmed across regions: stronger evidence of a broadly observable application failure.
Current monitor status still follows the full consecutive-failure and regional-confirmation policy.
Diagnosis versus incident diagnostics
The Detailed Logs category is intentionally short. A confirmed incident can include deeper DNS, TCP, TLS, HTTP, and regional evidence collected when the incident opens.
Use the incident page when you need that additional evidence. Do not treat either view as proof of an external provider's internal cause unless their own logs or status communications confirm it.