Skip to main content

Read an incident detail page

Use the incident header, root-cause summary, regional evidence, activity log, diagnostics, nearby checks, and JSON export to investigate a problem.

The Incident Details page brings together the saved incident record and nearby evidence. It loads a compact summary first, then retrieves larger troubleshooting sections only when needed.

Header and status

The header identifies the monitor and whether the incident is Active or Resolved. It also shows the monitored URL and notes when the monitor is currently paused.

The summary cards show:

  • Status: Active or Resolved.
  • Duration: elapsed incident time or the final resolved duration.
  • Started: the confirmed incident start in your selected account time zone.

Use Go to monitor or Back to Monitor to return to the monitor's charts and settings.

Root Cause

Root Cause displays the best available normalized diagnosis from the incident and nearby failed-check evidence, such as timeout, DNS, SSL, blocked request, authentication required, rate limiting, or server error.

The recommended action below it is a troubleshooting starting point. It is not a guaranteed explanation of the website owner's internal systems. Use the linked troubleshooting guide and supporting evidence before drawing a final conclusion.

Regional Confirmation

This section summarizes the failure cycle used as regional evidence. It can show:

  • The confirmation policy.
  • Primary monitoring region.
  • Regions that failed.
  • Regions that remained healthy.
  • Whether the primary failure was region-confirmed.

Regional confirmation describes reachability from monitoring locations. It does not identify the website's internal root cause by itself.

Activity Log

The Activity Log loads after the core page and combines incident-period events. Use the filters to show:

  • All activity.
  • Checks observed during the incident.
  • Alerts and their delivery outcomes.
  • System events such as resolution.

Long runs of similar checks or notifications are grouped. Expand a group to inspect individual entries and timestamps.

Request and Response

Request shows the monitor method and URL used for the availability check.

Response summarizes the available HTTP status, response time, error, diagnosis category, reason, and regional confirmation summary. It does not expose saved authentication secrets or custom-header values.

Diagnostics

When captured, the Diagnostics summary separates the network path into:

  • DNS: public addresses resolved during diagnostics.
  • TCP: whether the target port accepted a connection.
  • TLS: certificate and secure-connection information for HTTPS.
  • HTTP: the response status or request error.

Select View full diagnostics to load the complete diagnostic record. Diagnostics are requested when an availability incident opens, but they are not guaranteed. A cooldown, protection rule, delayed worker, old incident, or unavailable target can leave the section partial or empty.

Performance incidents can have less network diagnostic information because their primary condition is successful but slow responses.

Checks Around Incident

Expand Checks Around Incident to load nearby checks on demand. The table includes time, Up or Down result, HTTP code, latency, diagnosis, regional confirmation, and error.

This is a bounded troubleshooting view around the incident, not a replacement for the full retained dataset. Open Detailed Logs when you need filters, more pages, or CSV export.

Download incident data

The Download incident data button creates a JSON export containing the incident details available to your account, including the core record and supporting sections. JSON is intended for technical review, support escalation, and retaining a case attachment.

Review exports before sharing them outside your organization. They do not include saved request secrets, but they can contain monitor URLs, timestamps, diagnostic addresses, and operational details.

Why older incidents can show less detail

Incident records remain for the life of the monitor, while raw checks and Alert History expire sooner. An older incident can therefore retain its start, recovery, duration, and saved diagnostics after some nearby activity is no longer available.

Related articles

Did this answer your question?

Your response helps improve this Help Center.