Start an incident investigation with the first failed check, then compare the runs that confirmed the incident and any later recovery. WebCheck’s incident page puts the diagnosis, timeline and related check evidence together.
Read the diagnosis and timeline
Open the incident from the site page or check history. Read “What happened,” the possible causes and the recommended next step. The timeline shows the first failure, when the incident was confirmed and whether recovery has been detected.
An incident opens after the target’s configured number of consecutive Failed or Blocked runs. A single response may therefore not be the cause of a confirmed incident; compare the entire failure sequence.
Compare the check runs
Use the incident filters to view all runs, failures only, recovery runs or the preceding context. Compare the HTTP status, error code, response timing, final URL, redirect path, resolved address and any available evidence. Match the timestamps to deployments, DNS changes, firewall or CDN events, and application logs.
For DNS, TLS, content or safety errors, follow the linked explanation and related guide. A Blocked result means WebCheck refused an unsafe destination; it does not prove that the application itself is down.
Confirm recovery
Recovery requires the configured number of consecutive Passed runs. Degraded runs do not recover an open incident. After making a change, use “Run now” when available, then review the recorded result and wait for the configured recovery threshold.