Incident forensics — what actually happened

An alert that says "your site is down" leaves you doing the debugging. When CompleteStatus confirms an outage and opens an incident, it automatically captures failure forensics — diagnostic evidence from the exact moment of the failure — and attaches it to the incident. By the time you open the alert, the incident page already shows what the check saw.

Forensics are captured only for confirmed outages — the second consecutive failed check that opens the incident. A single transient failure never triggers a capture (and never alerts).

What gets captured

Response snapshot — every plan

Persisted from the confirming failed check itself, at the moment it failed:

• The exact error — timeout, TLS handshake failure, connection refused, DNS resolution failure, or the unexpected HTTP status.
• Timing phases — DNS lookup, TCP connect, TLS handshake, time-to-first-byte and total time in milliseconds, so you can see where the request spent its time before failing.
• Response headers — with Set-Cookie removed (session tokens are never stored).
• Response body — the first 16 KB, enough to see the error page or JSON error envelope your server returned.

For HTTP uptime monitors the snapshot carries all of the above. Other monitor types (port, SSL certificate, DNS, domain, and so on) store a leaner snapshot: the error, the status code where one exists, and the coarse timings the check recorded. Heartbeat monitors are push-driven — there is no request to snapshot, so their incidents carry no forensics.

The snapshot also powers the one-line diagnosis in your alerts: instead of a raw error string, the notification says things like TLS handshake failed or HTTP 502 after 1.9s at TTFB. Full dumps never go to chat channels — the alert links to the incident, which has everything.

Traceroute — Business plan and above

A bounded traceroute (max 20 hops, hard time limit) runs from the monitoring worker to your monitor's host and records each hop's hostname, IP and round-trip time. When your origin is fine but a network path or upstream provider is not, the traceroute shows where packets stop.

• Runs asynchronously — it never delays checks or alerts. The incident page shows "capture pending" until it lands.
• Hops that do not reply (many routers silently drop probe packets) appear as * rows; that is normal and does not mean the trace failed.
• The trace targets the same validated IP address the check connected to.

Screenshot — Pro plan and above

For monitors whose target is an HTML page (HTTP uptime, keyword, content change, security headers, page health), a headless browser on the worker loads the failing URL and captures a screenshot. If your site is serving an error page, a hosting-provider splash screen or a half-rendered layout, you see exactly what your visitors saw.

The screenshot is captured asynchronously right after the incident opens and appears on the incident page — thumbnail in the sidebar, click for full size. Non-HTML monitors (port, heartbeat, DNS, certificate) skip this step.

Where to find it

Open any incident and the Diagnostics card sits directly under the header: the diagnosis line, timing phases, the response headers and body (collapsed by default), and the traceroute table. Captures run in the background, so an incident opened seconds ago may briefly show "capture pending"; a resolved incident that never got a capture shows "not available".

Retention

• Response snapshots and traceroutes are kept for 90 days, then pruned automatically. Evidence attached to a still-open incident is never pruned, regardless of age.
• Screenshots follow the same 90-day window (and are likewise protected while their incident is open).
• The incident itself — timeline, cause, postmortem — is unaffected by forensics pruning.

Privacy and sensitive data

Response snapshots store real response headers and up to 16 KB of real response body. If the monitored endpoint returns secrets (API keys, personal data, internal hostnames), those end up in the snapshot:

• Set-Cookie headers are always stripped before storage — session and auth cookies are never persisted.
• Snapshots are stored in CompleteStatus's database alongside your check results. They are not separately field-level encrypted (unlike stored credentials such as basic-auth passwords and API tokens, which are); protect-at-rest relies on database and disk encryption of the deployment.
• Forensics are visible only to members of your organization, exactly like the incident itself. Nothing from a snapshot ever appears on public status pages.
• Everything is deleted automatically by the retention window above.

If an endpoint returns data you must not retain even for 90 days, monitor a health-check route instead of the data-bearing route — good practice regardless of forensics.

Plan availability