Postmortem (DevOps)
A postmortem is a written report produced after an incident that documents its timeline, root cause, impact, and follow-up actions, with the goal of preventing the same failure from recurring rather than assigning blame.
Definition
A postmortem is a written report produced after an incident that documents its timeline, root cause, impact, and follow-up actions, with the goal of preventing the same failure from recurring rather than assigning blame.
Overview
Once an outage or major incident is resolved, the work isn't over — a postmortem captures what actually happened while details are fresh: when the problem started, how it was detected, what responders tried, what ultimately fixed it, and how long customers were impacted. The defining principle in most modern practice is that postmortems should be blameless: the goal is to understand what conditions in the system and process allowed the failure to happen, not to identify which individual made a mistake, since punishing individuals discourages the honest reporting a good postmortem depends on. A strong postmortem goes past the immediate trigger to find contributing root causes — often several, since most real incidents involve a chain of smaller failures rather than one single cause — and produces a concrete list of follow-up action items with owners and deadlines. Without that follow-through, a postmortem is just a record of an incident that's likely to repeat. The practice was popularized as a core part of site reliability engineering (SRE), where postmortems feed directly back into runbooks, alerting thresholds, and observability gaps identified during the incident. Many teams also track completion of postmortem action items as a metric in its own right, since a pattern of unfinished follow-ups is itself a sign of accumulating operational risk. Some organizations share postmortems more broadly, or even publish select ones publicly, as a way of building trust and modeling transparency around failure.
Key Concepts
- Blameless framing focused on systemic causes, not individual fault
- A detailed, timestamped timeline of detection, response, and resolution
- Root cause analysis that looks beyond the immediate trigger to contributing factors
- Concrete follow-up action items with clear owners and deadlines
- Impact summary covering duration, affected users, and business consequences
- Tracked completion of action items as an ongoing reliability metric