Incident diagnostics collect a bounded external snapshot of DNS, TCP, TLS, and HTTP behavior. They do not inspect your private infrastructure, record a complete browser session, capture response bodies, or determine the website's internal root cause with certainty.
Use diagnostics as supporting evidence alongside your own service logs.
Diagnostics are a point-in-time external test
Uptime Basics requests diagnostics when a confirmed availability incident opens. The diagnostic run is separate from the scheduled checks and regional confirmation that established the incident.
Diagnostics can finish after the incident begins, can return partial information, and are not guaranteed. They are not continuous packet recording and are not automatically rerun when you expand the section or download incident data.
A successful diagnostic after failed checks can mean the service recovered or the problem was intermittent. It does not erase the earlier region-confirmed evidence.
Information that can be collected
The bounded record can contain:
- up to eight public IPv4 and eight public IPv6 DNS answers;
- one TCP connection result for the selected public address and target port;
- TLS authorization state, protocol, cipher, certificate subject, issuer, expiry, and estimated days remaining;
- HTTP status, request duration, error, and selected response headers;
- monitored URL, hostname, request method, timestamp, and diagnostic region; and
- the first failure summary supplied by the incident.
The selected HTTP response headers are limited to Server, Content-Type, Cache-Control, Location, Date, and Retry-After when present. Retry-After is shown as an informational diagnostic for rate-limited responses; it does not change your monitor's configured schedule.
Public IP addresses and operational details in a diagnostic export can still be sensitive in context. Review them before sharing.
Response content is not collected
Diagnostics do not collect:
- the HTTP response body;
- HTML source or visible page text;
- screenshots, video, or a rendered page;
- Document Object Model content;
- JavaScript console output;
- browser network waterfalls;
- cookies, local storage, or browser sessions; or
- CAPTCHA, consent, login-form, or interactive multi-factor-authentication results.
The HTTP response stream is discarded after the status and selected headers are read. Uptime Basics does not perform keyword, visual, or transaction checks through incident diagnostics.
Saved monitor secrets are not used or exposed
The separate diagnostic request does not include the monitor's saved custom request-header values or Basic Authentication password.
Diagnostics and incident exports do not expose:
- custom-header secret values;
- Basic Authentication passwords;
- authorization tokens;
- session cookies;
- verification codes;
- private keys; or
- encrypted secret material.
Because the diagnostic request is intentionally limited, a protected endpoint can fail diagnostics even when its normal configured monitor request has the required supported credential. Compare the scheduled check and regional Confirmation evidence before interpreting that difference.
Private systems are not inspected
Diagnostics cannot access or collect:
- application, web-server, WAF, firewall, CDN, or load-balancer logs;
- hosting control panels or cloud-provider consoles;
- CPU, memory, disk, process, container, or server-health metrics;
- database, queue, cache, or internal API state;
- deployment history or source code;
- customer records or private application data;
- private, loopback, local, reserved, or internal network targets; or
- data from your device, browser, office network, or internet provider.
Only supported public HTTP or HTTPS targets on ports 80 and 443 are accepted.
Network-path details are not collected
Diagnostics do not perform:
- traceroute or hop-by-hop route mapping;
- packet capture;
- broad port scanning;
- vulnerability scanning;
- traffic interception;
- a test of every IP address returned by DNS; or
- a complete test from every regional confirmation location.
Regional confirmation is separate and reports whether other monitoring regions reproduced an availability failure. The DNS, TCP, TLS, and HTTP diagnostic record is not a full multi-region network trace.
DNS and TLS checks are intentionally limited
DNS diagnostics look for public A and AAAA answers. They are not a complete DNS-zone audit and do not collect every record type, provider setting, nameserver log, DNSSEC proof, or resolver cache state.
TLS diagnostics examine the certificate and connection presented during that run. They are not an exhaustive certificate-chain, revocation, OCSP, cipher-inventory, or external compliance audit.
Optional SSL-expiry monitoring is a separate daily feature. Incident diagnostics do not replace it.
HTTP diagnostics do not prove application health
An HTTP response proves that the tested endpoint returned a result under that diagnostic request. It does not prove that:
- every page or API route works;
- a user can sign in or complete a transaction;
- all dependencies are healthy;
- every geographic region can connect;
- a returned challenge page is the intended application; or
- the provider's internal systems are fully operational.
Similarly, an HTTP error identifies the observed external response but cannot name the internal code path or configuration that produced it.
What to compare instead
Use the diagnostic timestamp to compare:
- Detailed Logs and regional Confirmation.
- Checks Around Incident.
- DNS-provider and registrar records.
- CDN, WAF, firewall, load-balancer, and reverse-proxy logs.
- Web-server and application logs.
- Deployment, scaling, maintenance, and infrastructure events.
- An official provider status page when a third-party dependency is involved.
The most reliable root-cause conclusion usually combines independent external evidence with the system owner's internal records.
Share diagnostic data safely
When contacting Support, provide the monitor name, incident timestamp, displayed diagnosis, regional summary, and a sanitized description of matching server-side evidence.
Do not send passwords, header values, cookies, tokens, private keys, verification codes, customer data, or unrestricted account access. Uptime Basics Support will not ask for those secrets.