Post-mortems
Write a structured retrospective on any incident — severity, root cause, timeline and tracked action items — and optionally publish it to your status page.
A post-mortem turns an incident into an improvement: what broke, why, and what you'll change so it doesn't repeat. WatchFor post-mortems live directly on the incident page, so the evidence (timeline, probe data, notes) is one scroll away while you write.
Post-mortems are a plan feature — if the section shows as locked, they aren't included in your current plan.
Where they live
Post-mortems have their own section: Post-mortems in the sidebar, right next to Incidents. The list shows every retrospective with its status (draft / completed / public), severity, root-cause category, open action items and last update — so unfinished drafts and unclosed follow-ups can't hide.
Writing one
Two ways to start:
- From the Post-mortems list — Add post-mortem shows recent incidents that don't have one yet; pick one and the editor opens.
- From any incident page — the compact Post-mortem card has a Start post-mortem button (and later shows the summary with a link to the full editor).
Either way you land on the dedicated post-mortem page: incident context (monitor, status, start time, link back to the incident) on top, the editor below. The draft is pre-filled with a template covering the sections every good retrospective answers: Summary, Impact, Root cause, Detection, Resolution, What went well, What could have gone better. You can start before the incident is resolved — the draft badge stays until you mark it completed.
Alongside the document you set two structured fields:
- Severity — your after-the-fact assessment (minor / major / critical), independent of the alert severity that fired.
- Root cause category — deploy, configuration change, third-party dependency, capacity, network, hardware, security, human error…
The document opens in a rich editor — format with the toolbar (headings,
bold, italic, code, bullet lists) or the usual Ctrl+B / Ctrl+I shortcuts,
no syntax to learn. Prefer plain text? The Markdown tab edits the same
document as lightweight markup (## headings, **bold**, - lists), and
Preview shows exactly how it will render — including on the public status
page.
Timeline
The timeline starts with the incident's automatic events (started, resolved) and lets you add your own entries — when the first deploy went out, when the rollback finished, when the customer impact actually stopped. Times follow your profile's timezone and 12/24-hour preference.
Action items
The part that makes a post-mortem more than a document: a tracked list of follow-ups with an assignee (any team member), a due date and an open/done state. Overdue items are flagged, and the section header keeps the open count visible — so "we should add a retry" doesn't evaporate after the meeting.
Completing and publishing
Mark completed freezes the status (you can always reopen). Owners and admins can additionally flip Publish to status page: when this incident is also published as a status page incident, the completed post-mortem appears on the public incident page — title, severity, root-cause category, the document and the follow-up actions (without assignee names).
Public post-mortems are one of the strongest trust signals an engineering team can ship: they show your users that outages get understood, not just closed. Nothing is ever shown publicly unless you explicitly publish it — and internal notes always stay private.
Activity log
Every post-mortem event — started, completed, reopened, published, action items added and closed — lands in the organization activity log with the actor and timestamp.