Incident updates and timeline

Keep a running record of what's happening during an incident.

Plan availability

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

Overview

Every incident has a timeline — a running record of what happened, in order. It mixes two kinds of entry:

• System entries, added automatically by DomainDash as the incident unfolds.
• Notes, written by your team to add context the checks can't capture.

Together they give you a single place to see both the facts (what the checks saw) and the story (what your team did about it) — so when someone asks "what happened?" days later, the answer is already written.

Detection and email down-alerts run on every plan, but the timeline and team notes are part of the Incidents feature.

System entries

DomainDash adds system entries on its own as the incident moves through its lifecycle. These cover things like the incident opening, a check's status changing, a location going down or recovering, and the incident being resolved. They're the factual record of what the checks observed, so you can't edit or remove them.

For how those transitions work — confirming, open, recovering, resolved — see How incidents work.

Team notes

Notes are how your team adds the human context the checks can't. Use them to record what you're seeing, what you've ruled out, and what you've changed — for example, "Rolling back deploy #2341, ETA 5 mins." Notes appear inline on the timeline alongside the system entries, attributed to whoever wrote them, so everyone stays on the same page instead of repeating each other's work.

You post a note from the incident detail page, in the Post an update box. Anyone on your team can read notes; they're internal by default.

Editing and deleting your own notes

You can edit and delete the notes you posted yourself. You can't change notes written by other people, and you can't touch the automatic system entries — those stay as the record of what actually happened. An edited note is marked as edited so the timeline stays honest.

Post-mortem notes

A note you add after an incident has resolved becomes a post-mortem note. These are grouped separately, under a "Post-mortem" heading marked "Written after the incident", rather than mixed into the live timeline. It's the natural home for the lasting write-up: the root cause, what you changed, and what to watch for next time — so the same incident doesn't catch you out twice.

Internal notes vs public updates

Everything above is internal — only your team sees it on the timeline. That's different from a public update, which is published to your status page for your customers to read, tied to a friendly status like "Looking into it" or "Fixed".

The two share the same composer (you choose Team only or Public before you write), but public updates need a status page and the right permissions. See Publishing public updates for the details.

Related

• Publishing public updates to share progress with customers on your status page
• Incident detail page for the rest of the incident view
• How incidents work for the incident lifecycle behind the system entries
• Incident history to browse resolved incidents and their post-mortems