What sections does a standard incident postmortem document contain, and what is each section for?

## What the document is actually for A postmortem is not a report filed to prove that an incident was taken seriously. It is a mechanism with two outputs: a shared, accurate account of what happened that anyone in the company can read months later, and a short list of changes that make the next occurrence less likely, less severe, or faster to catch. Every section of the template earns its place by feeding one of those two outputs. If a section feeds neither, cut it — long templates get filled in ritually and read by nobody. The canonical section list most companies use descends from the example postmortem published in Google's SRE book (2016). Names vary between houses; the spine does not. ## Metadata and summary Title, date, authors, status (draft / in review / final), and a two-or-three-sentence summary. The status field matters more than it looks: a postmortem that sits in "draft" forever is one of the classic failure signatures, and having the state on the document makes that visible. ## Impact What customers experienced, quantified, and for how long. "Checkout returned 5xx for 41 minutes; approximately 12,000 requests failed; 3 enterprise customers opened tickets." This section comes first because it is what non-engineers read, and because it is the number that later justifies — or fails to justify — the cost of the action items. An impact section written as "the service was degraded" is not usable for prioritization. ## Timeline A list of timestamped events, in UTC or one clearly stated zone: first error, first alert fired, human acknowledged, incident declared, mitigation applied, recovery confirmed, incident closed. The timeline is the raw material for the durations you care about — time to detect, time to mitigate, time to resolve — and those durations are usually where the improvable gap is. A team that took eight minutes to fix a problem it took ninety minutes to notice has a detection problem, not a fix problem, and only a timestamped timeline makes that obvious. Narrative entries like "we recovered sometime in the afternoon" destroy the section's value. ## Detection and resolution How you learned about it (an alert, a customer ticket, an engineer noticing a graph) and what actually restored service. Separating these from the timeline forces an honest answer to "would we have caught this without the customer telling us?" ## Analysis: contributing factors What combined to produce the outage. Keep it factual and mechanism-level. How you *conduct* that analysis — the questioning technique, trigger versus underlying cause, why one "root" cause is usually a fiction — is a discipline of its own and is not what the template section is for; the section is just where its output lands. ## Lessons learned: went well / went wrong / got lucky The three-way split is not decoration. **What went well** protects the practices that worked so a later reorganization does not delete them by accident. **What went wrong** is the source list for action items. **Where we got lucky** is the section people skip and the one that most often predicts the next outage: the failure landed at 03:00 when traffic was one-tenth of peak; the one engineer who knew the subsystem happened to be awake; the corrupted replica happened to be the one that was already out of rotation. Luck is not a control. Anything recorded here is a risk you are still carrying, and it frequently converts directly into an action item. ## Action items A table, not a paragraph. Each row: the change, a type (commonly *prevent*, *mitigate*, *detect*, or *process*), a named individual owner, a priority, and a link into the tracker where the work actually lives. The table is the only part of the document that changes the system; everything above it is the evidence that the rows are worth doing. ```markdown | Action | Type | Owner | Priority | Tracker | |---|---|---|---|---| | Add jittered retry budget to checkout client | prevent | priya.n | P1 | REL-482 | | Alert on replica lag > 30s | detect | tomas.k | P1 | REL-483 | | Add "drain region" step to the runbook | mitigate | priya.n | P2 | REL-490 | ``` ## Supporting information Graphs, log excerpts, chat transcript links. Useful, and deliberately last — the document must be readable without it. ## What a template cannot do A template standardizes the *shape* of the record so it is searchable and comparable across dozens of incidents. It does not make the content honest, does not make the analysis deep, and does not make the action items happen. Teams that adopt a template and see no change in reliability have usually adopted only the shape.