Incident detail page

The full picture of what went wrong, what's happening now, and what your team has done about it.

Overview

Every incident in DomainDash has its own detail page. It has a live status header, a checklist of what DomainDash checked, and a timeline of every event from the moment the problem was first detected through to resolution.

Plan availability

Incidents is available on Pro and Business. See the plan comparison.

The incident detail page is part of the Incidents feature. On plans without it, you'll see the incident's type and severity, but the full timeline, check status, timings, and team notes need an upgrade.

You can reach the incident detail page in three ways:

• From the incidents list. Click any row in your incident history to open the full detail view.
• From a site's alert banner. When a site has an active incident, the banner on its detail page links straight here.
• From a notification. Urgent alert and resolved emails include a direct link to the incident.

Status header

At the top of the page, a header card shows the key facts:

• Status badge carrying the headline. While the incident is live it reads the severity and type together (P2 · Slow response, for example) and once it's over it reads Resolved. The badge's colour, and a gentle pulse while it's live, show the current state. There's no separate open or recovering label. The severity codes (P0, P1, P2, P3) are the levels we call Urgent, Needs fixing, Needs a look, and Worth knowing.
• Ongoing (or Lasted, once resolved) showing how long the incident has been running: counting up live, or the total time it lasted once it's over
• Started showing when the incident was confirmed, with a relative time underneath (for example, "12 minutes ago")
• Checked from showing how many locations are running the check (for example, "Checked from 4 locations"), with the locations seeing the problem listed underneath on uptime incidents
• Resolved (resolved incidents only) showing when the incident was marked resolved

As checks come in and the incident progresses, the badge, elapsed time, and location count change to match.

What we checked

Below the header, a checklist card shows the current health of each check for the affected site:

Check	What it covers
Response time	Whether the site is responding to uptime checks
Security	Whether the SSL certificate is valid and current
Domain routing	Whether DNS is resolving correctly
Domain registration	Whether the domain registration is active

Each item shows a status: healthy, warning, or failing. A badge at the top of the card shows how many checks are currently failing (for example, "1 of 4 failing"), and a one-line summary spells out which ones. Each item has a Details link that takes you to the relevant section of the site detail page for a deeper look.

The checklist shows the site's state now, which may differ from when the incident opened.

Timeline

The main body of the page is a chronological timeline showing everything that's happened during the incident, oldest first. There are two kinds of entries:

System-generated entries

DomainDash adds entries as the incident progresses:

• Pre-incident summary — a snapshot of what was happening just before the incident was confirmed, including recent failure counts and the first location to detect the problem
• Opened and resolved — markers for when the incident was confirmed and when it was resolved
• Location changes — when an individual location starts seeing the problem or recovers
• Failure counts — periodic summaries of how many checks have failed across your locations

Together they record what happened without anyone on your team having to write it down.

Team updates

Your team members can post their own entries to the timeline:

• Internal notes on active incidents, for coordinating your response ("Restarting the web server", "Contacted hosting provider")
• Post-mortem notes on resolved incidents, for recording what happened and why ("Root cause was an expired database certificate")

These notes stay inside DomainDash: your team can see them, but visitors to a public status page can't. Each entry shows who created it and when.

Posting updates

A composer is fixed to the bottom of the page. On an active incident, type a message and click Post update to add it to the timeline as an internal note. Once the incident is resolved, the button reads Add note and your message becomes a post-mortem note.

Any member of the team that owns the site can post internal notes. You can edit or delete your own notes after posting. Those are the only actions on an incident: you can't change its severity, or resolve, close, or reopen it by hand.

Publishing to a public status page

If your site has a public status page, owners and admins can click Publish update so an update appears for visitors as well as your team. Publishing needs a plan with status pages, and it's separate from posting an internal note. See publishing public updates for the full flow.

Collaborate during an incident

Everyone watching the incident sees new notes as they're posted, so your team can coordinate a response here without switching to a separate chat tool.

Live updates

Everything on the incident detail page updates in real time without refreshing. The whole team can watch an incident unfold together, or check back later and see the complete picture.

Related

• How incidents work for detection, severity levels, and recovery confirmation
• Incident history to browse and filter all incidents across your sites
• Notification channels for how and when you're alerted about incidents
• Site detail page for the overview of an individual site's health