Incident evidence
Incident Evidence: Screenshots, Failed Steps and Network Context
Move from a vague downtime alert to evidence that shows what the customer experienced and where the journey stopped.
What you will learn
- A timestamp and red status are rarely enough to diagnose a failure.
- The failed step identifies where the customer journey stopped.
- Screenshots explain visible state; network and console data add cause clues.
- Sensitive values must be masked before evidence is retained.
Detection is only the first question
A conventional alert tells the team that something failed at a particular time. The first response is usually another question: what exactly happened? If the failure has already recovered or only appears under specific timing, manual reproduction may not provide the answer.
Incident evidence preserves the state observed by the monitor. For browser journeys, that starts with the ordered step results and the exact step that failed.
What each evidence type contributes
A screenshot shows the visible customer experience: an error message, missing control, unexpected modal or incomplete layout. Console events can identify JavaScript errors. Network context can show a rejected request, slow dependency or failed API response.
No single artifact is always sufficient. Together they narrow the search space and give product, support and engineering teams a common representation of the incident.
- Step name, status and duration
- Screenshot captured at failure
- Redacted console events
- Relevant network request context
Protect sensitive information
Evidence can capture authenticated pages and form values. Monitoring systems should mask secret references and sensitive fields before screenshots or traces are stored. Access to evidence may need stricter permissions than access to uptime summaries.
Retention should match the purpose of the evidence and the customer agreement. Longer is not automatically better when artifacts may contain operational context.
Connect evidence to one incident timeline
Evidence should be attached to the confirmed incident alongside failed and recovery runs. That preserves chronology and prevents artifacts from becoming disconnected files with no operational meaning.
CrawlPanel captures step-level browser results, screenshots and technical context so alerts can link directly to the information needed for investigation.
Frequently asked questions
Why are screenshots useful in monitoring?
They preserve the visible page state at the time of failure, which may be difficult or impossible to reproduce later.
Can monitoring evidence contain sensitive data?
Yes. Secrets and sensitive fields should be masked, evidence access controlled and retention limited appropriately.