One review per incident#
A postmortem records what happened, why, how it was detected and resolved, and the action items that stop it recurring. Postmortems, under Respond, lists what is due, in review and published. Everyone who can see an incident can read its review; responders, team admins and organization admins can write one. Resolved incidents offer Start postmortem or Open postmortem.
Automatic drafts and reminders#
The “Postmortem expected from” setting on the Organization page under Settings sets the severity threshold. The default is P2, so every resolved P1 and P2 incident is listed as waiting for a review until one exists; none turns the reminder off.
- Every minute, the worker creates a draft for incidents resolved in the last 24 hours that meet the threshold and have no review yet.
- The owner is the incident's assignee, otherwise whoever acknowledged it, otherwise nobody. Service accounts are never owners.
- The due date is the resolution time plus Postmortem due after (days): default 5, from 1 to 60.
- When a review is past due, the owner is emailed through the organization's email provider, or the owning team's team admins when there is no owner. The reminder repeats every 3 days until the review is published.
Write the review#
The editor opens with a draft prefilled from the incident: a title, when and how it was detected, time to acknowledge, time to resolve, and the full timeline beside the form with notifications filtered out. The sections are Summary, Impact, Root cause, Detection, Resolution, What went well, What went badly and Lessons learned. Each action item has a text, an optional owner, a due date and a done box.
Review statuses#
| Status | Meaning |
|---|---|
| draft | Being written. |
| review | Ready for the team to read and comment before publishing. |
| published | Final. Requires a summary and a root cause. |
Each status change is recorded on the incident timeline and in the audit log. Export Markdown downloads the review with its timeline for a wiki or a ticket.