Incident response
What a Confirmed Website Incident Looks Like
An anonymized CrawlPanel incident shows how a confirmed 502 failure is recorded with a clear status, protected browser evidence and an event timeline that makes the next decision easier.
What you will learn
- Confirmation separates a persistent incident from a one-off failed request.
- A useful incident record shows the status, scope and elapsed time at a glance.
- Protected browser evidence helps teams diagnose before they reproduce the failure.
- A timeline gives every response and recovery decision a shared record.
A real incident should begin with confirmation
A single failed request is a signal, not necessarily an incident. Networks are noisy, services deploy and upstream dependencies can briefly misbehave. A monitoring workflow should apply its confirmation policy before it opens an incident, so the team can react to a problem that is likely to persist instead of chasing every transient error.
The anonymized example below shows that handoff. The incident is open because the monitor received a response outside its accepted status range. Customer, workspace, account and timestamp details are deliberately blurred, while the operational context remains visible.
- The expected response or assertion
- The confirmation threshold that opened the incident
- The current severity and status
- The time the problem has been active
The record should answer the first questions in seconds
The top of an incident page should make the first triage questions easy to answer: what is failing, how serious is it, when did it begin and how many confirmed failures have occurred? Those details keep an alert from becoming a hunt through logs, chat threads and dashboards.
In this case, the incident label, medium severity, open state, duration and failure count are visible without opening another view. Acknowledge and resolve controls make ownership explicit while the investigation is in progress.
- Name the affected monitor or customer outcome
- Show the incident state and severity clearly
- Keep opened time, last update and duration together
- Allow acknowledgement and resolution to be recorded
Evidence closes the gap between detection and diagnosis
An alert that says a URL failed is useful, but it still leaves the responder asking what the visitor actually saw. Browser evidence can answer that question immediately. Here, the protected snapshot captures a 502 Bad Gateway page after the incident was confirmed, narrowing the investigation toward the application path or an upstream dependency.
Evidence should be handled carefully. CrawlPanel keeps incident screenshots protected and available only to people with access to the relevant project. For this article, the screenshot was anonymized before publication. The same principle applies to screenshots, request details, credentials and any other customer data used during incident response.
- Capture the page state after confirmation
- Preserve the failed step or assertion
- Restrict access to project members
- Use anonymized examples for external communication
The timeline makes the response reviewable
An incident is more than a red status. The timeline records when the failure was confirmed, when evidence was captured, when a person acknowledged the issue and when recovery was detected. This creates one durable account of the event instead of relying on memory or scattered messages.
That record helps during active response and later review. Teams can see the real duration, distinguish detection time from acknowledgement time and identify where a handoff or escalation could improve.
- Incident opened after confirmation
- Evidence captured
- Acknowledged or investigated
- Recovered and resolved
Do not stop at the first green check
Recovery is part of the incident lifecycle. When the monitor returns to its expected state, the team needs a clear recovery signal and a final resolution record. That closes the loop for everyone who received the original alert and prevents unnecessary duplicate investigation.
The lesson is simple: a good incident view should help people move from detection to explanation to recovery with as little friction as possible. That is why CrawlPanel connects confirmation, protected evidence, timeline events and recovery in one workflow.
Frequently asked questions
What turns a failed website check into an incident?
A failure becomes an incident when it meets the monitor policy for confirmation, such as a second failed run or a defined failure threshold. Confirmation helps reduce alerts caused by brief transient problems.
Why capture a screenshot for a website incident?
A screenshot shows what a visitor or monitor saw at the time of the confirmed failure. It can reveal an error page, empty content, a blocked interaction or another clue that is difficult to infer from a status code alone.
How should incident evidence be shared safely?
Keep production evidence available only to authorized project members. Before using a screenshot externally, remove or blur customer domains, workspace names, account details, timestamps and any other identifying or sensitive information.