Anatomy of a Good Postmortem: The Sections That Matter

A postmortem template is a contract with the reader: every incident gets written up the same way, so anyone can open the doc and find what they need in seconds. But templates accumulate cruft. Teams copy sections from a blog post, never question them, and end up with documents that are half boilerplate. This guide walks through the sections that actually earn their place, what each is for, and where the real value hides.

The sections, and what each one does

Think of a postmortem as answering four questions in order: What happened? Why? What did it cost? What are we going to do about it? Every good section maps to one of those.

Summary — the part most people read

The summary is the only section many people will read. Executives, adjacent teams, the engineer who joins next quarter and greps the wiki. Write it for them: three or four sentences, no jargon, covering what broke, who was affected, how long, and how it ended. If your summary requires knowing your internal service names, rewrite it.

Impact — the section that drives prioritization

Impact is where you quantify the damage: requests failed, customers affected, revenue at risk, SLO budget burned, internal teams blocked. This is not busywork. Six months later, when someone is deciding whether to fund the fix, the impact number is the argument. “Roughly 4,100 customers saw a failed checkout over 22 minutes” justifies work; “some users were affected” justifies nothing.

Detection — the gap nobody wants to measure

How did you find out? An automated alert, a customer tweet, or an engineer who happened to glance at a graph? And crucially: how long between the incident starting and you knowing? That gap — time-to-detect — is often the single biggest lever on total incident duration, and it hides unless you give it a named section.

Timeline — the spine

The timeline is the factual backbone everything else rests on. Timestamp every meaningful event: first symptom, alert firing, human acknowledgment, key diagnostic findings, the fix, and full recovery. Build it from artifacts — logs, chat, graphs — not memory. A good timeline lets a reader who wasn’t there reconstruct the incident and check your analysis against the facts.

Root cause(s) — plural, and honest

This is the analysis section, and it should be visibly separate from the timeline. The timeline is facts; root cause is interpretation. Name the chain of conditions, not a single culprit. And stop chasing “why” once you reach something you can actually change — going three more levels into human psychology produces philosophy, not action items.

What went well — the section teams skip

The most commonly deleted section, and one of the most valuable. If the rollback worked, if an alert fired correctly, if the on-call escalated cleanly — record it. When you start changing the system based on this incident, you want a list of the things that saved you so you don’t accidentally break them.

Where we got lucky — the free lessons

Near-misses inside the incident. “The failover worked, but only because the secondary happened to be in a different AZ — we don’t actually enforce that.” These are the cheapest lessons you’ll ever get, because they cost you nothing this time. Most teams never write them down.

Action items — the entire point

Everything upstream exists to produce good action items. Each one specific, owned by one person, tracked in a real ticket with a due date, and classified as prevent, detect, or mitigate. A postmortem with a beautiful timeline and vague action items has failed at its only job.

A quick section-value checklist

Use this to audit your template. If a section can’t answer “what decision does this help someone make later?”, cut it.

Summary — Can a non-expert understand the incident in 30 seconds?
Impact — Is it quantified, not “some users”?
Detection — Is time-to-detect explicitly stated?
Timeline — Built from artifacts, with the detection gap visible?
Root cause(s) — Plural, separated from the timeline, stops at something changeable?
What went well — Present, not skipped?
Where we got lucky — At least one near-miss captured?
Action items — Specific, owned, dated, typed, tracked?

Sections that usually don’t earn their place

Some templates carry sections that add length without adding value:

“Five whys” pasted verbatim. The reasoning is useful; the raw ladder of five literal “why?” lines usually isn’t. Summarize the causal chain instead.
A blow-by-blow narrative that duplicates the timeline. Pick one. The table is usually enough; a prose retelling is redundant.
A “who was involved” roster. In a blameless culture, a list of names attached to an incident invites exactly the reading you’re trying to avoid. Credit responders in the retro, not the permanent doc.

Keeping it lean

The best postmortems are shorter than people expect. A SEV-2 might be two pages. Length is not thoroughness — a tight timeline and three sharp, owned action items beat ten pages of narrative every time. When a section tempts you to pad it, ask what decision the extra words help someone make. If the answer is none, stop writing.

Wrapping up

A good postmortem is not a form to fill in — it’s four questions (what, why, what did it cost, what now) answered with just enough structure that any reader can find the piece they need. Keep the summary human, quantify the impact, make the detection gap visible, keep root cause plural and honest, and never skip “what went well” or “where we got lucky.” Then spend your remaining energy on the action items, because that’s the only section that changes the future.