Incident diagnostics separate a failed web request into DNS, TCP, TLS, and HTTP layers. They can narrow down where communication stopped, but they cannot inspect your private application, hosting control panel, or internal server logs.
When diagnostics run
Uptime Basics requests diagnostics when a confirmed availability incident opens. They are separate from the checks used to confirm the incident and can finish slightly later.
Diagnostics are not guaranteed. A protection cooldown, delayed worker, unavailable destination, security validation, or old incident can leave the result partial or unavailable. Performance incidents can also have less network diagnostic information because the monitored request succeeded but was slow.
DNS
DNS translates the monitored hostname into public IP addresses.
The DNS card can show:
- Whether public A or AAAA records were returned.
- A limited list of resolved addresses.
- How long the diagnostic lookup took.
- A lookup error when no usable result was available.
A DNS failure means the diagnostic process could not resolve the hostname at that time. It does not identify whether the cause was an expired domain, authoritative DNS outage, missing record, DNSSEC problem, or temporary resolver issue.
TCP
TCP tests whether a network connection can be opened to the target port. Uptime Basics supports public HTTP on port 80 and HTTPS on port 443.
If DNS succeeds but TCP fails, common possibilities include a firewall rule, unreachable host, routing problem, closed port, overloaded server, or timeout. The diagnostic does not perform traceroute and cannot name every network hop involved.
TLS
For HTTPS, TLS checks the secure connection and certificate presented for the hostname. The result can include:
- Authorization or certificate-validation state.
- TLS protocol and cipher.
- Certificate subject and issuer.
- Expiry date and estimated days remaining.
- A handshake, timeout, or validation error.
TLS incident diagnostics are distinct from optional daily SSL-expiry monitoring. Availability checks still validate HTTPS trust even when the optional expiry reminder is disabled.
HTTP
HTTP tests the configured URL using the monitor's request method. The card can show the returned status code, request duration, selected response headers, or a request error.
The diagnostic captures the response observed at that point in time. A successful diagnostic after a failed check can mean the site recovered or the issue was intermittent. It does not invalidate the earlier region-confirmed failure.
Interpret combinations
| Evidence | Practical interpretation |
|---|---|
| DNS failed | The hostname could not be resolved for diagnostics. |
| DNS passed, TCP failed | An address resolved, but the target port could not be reached. |
| TCP passed, TLS failed | The server accepted a connection, but HTTPS negotiation or validation failed. |
| TLS passed, HTTP failed | The secure connection worked, but the HTTP request timed out, errored, or returned an unacceptable result. |
| Every layer passed | The diagnostic did not reproduce the earlier failure; it may have recovered or been intermittent. |
View the complete record
The summary cards show the most important fields. Select View full diagnostics to load the stored JSON record, including timings and available technical details.
Treat diagnostic output as supporting evidence, not certainty. Compare it with your DNS provider, CDN, firewall, hosting, server, and application logs from the same time.
Security boundaries
Diagnostics only accept public HTTP or HTTPS targets on supported ports. Private, local, reserved, credential-embedded, and unsafe redirect targets are blocked. Saved authentication passwords and custom-header secret values are not exposed in the incident page or export.