Postmortem
A postmortem is a blameless written analysis after an incident that reconstructs the timeline, identifies contributing causes, and assigns durable follow-up actions.
Definition
A postmortem is a structured, blameless review of an incident that documents impact, timeline, contributing factors, detection gaps, and owned remediation items with due dates.
Context and scope
Written after incidents that breach an SLO, affect customers, or reveal a systemic gap, then reviewed in a recurring engineering forum.
Common misconceptions
- A postmortem must identify one root cause
- Blameless means nobody is accountable for the fixes
- Postmortems are only for major customer-facing outages
Anti-patterns
- Publishing a long narrative with vague causes and no owned actions
- Using the review to find a person to blame
- Closing action items without verification or follow-up
Related concepts
Authoritative source
How it works
The team reconstructs a timeline from logs, dashboards, and chat, measures impact in user terms, and identifies contributing factors rather than a single culprit. Action items get owners, due dates, and tracking so they do not dissolve. A review meeting shares the findings, and the document is published where the whole engineering organization can search it.
When to use it
Write one after any incident that breaches an SLO, harms customers, or reveals a systemic gap; also review near misses while the details are fresh. Small incidents can use a lightweight template. Compared with a ticket-only fix, a postmortem captures detection and coordination failures, not just the immediate bug.
Trade-offs
Postmortems cost senior time and can generate more action items than teams can absorb. Blameless does not mean accountability-free: owners still deliver. Template theater, meaning long documents with vague causes and no follow-through, erodes trust, so fewer, sharper actions beat exhaustive narratives.
Example
A checkout outage lasts thirty-seven minutes after an expired TLS certificate is deployed. The postmortem records the detection delay, assigns an owner to add certificate-expiry alerts, and schedules a game day to test the renewal runbook. All actions close within two weeks.
Misconceptions
A postmortem does not need to name one root cause; complex systems fail through several contributing conditions. Blamelessness protects honest reporting, not poor ownership of fixes. Nor is a postmortem only for severe outages, because recurring minor failures often teach more.
Related concepts
Incident command structures the response being reviewed; a runbook turns findings into repeatable mitigation; the error budget provides an objective trigger for the review.