Most postmortems fail in one of two ways. Either they become a polite ritual that produces a document nobody reads, or they quietly turn into a search for whoever pressed the wrong button. Both waste the one thing an incident gives you for free: a detailed look at how your system and your team actually behave under stress.

Blameless does not mean consequence-free or vague. It means starting from the assumption that people made reasonable decisions with the information they had, and asking what about the system made the bad outcome possible.

Why Blame Gets You Worse Data

If engineers expect to be punished, they will leave out the awkward details. The command they were unsure about, the alert they ignored because it fires constantly, the dashboard they did not trust. Those details are precisely what you need.

Blame also lands on the wrong layer. “Engineer ran the wrong command” is rarely the real story. The real story is usually that the command was easy to run against production, nothing asked for confirmation, and the environments looked identical. Fix the person and the trap stays set for the next one.

Before the Meeting: Build a Timeline

Assign one person to draft a timeline from facts, not memory. Sources include chat logs from the incident channel, deploy history, alert history, graphs, and on-call notes. For each entry, record the time, what happened, and what people knew at that moment.

That last part is easy to skip and extremely valuable. Hindsight makes everything look obvious. Writing down what the responder could see at 02:10, which dashboards said what, which alert had fired, protects the discussion from “why didn’t you just…” questions.

Mark three moments explicitly: when the problem started (often earlier than when it was noticed), when it was detected, and when it was resolved. The gaps between them show you where to invest: detection, diagnosis or repair.

During the Meeting: Ask Better Questions

A facilitator who was not deeply involved in the incident tends to run this best. Their job is steering, not defending.

Replace “who” and “why did you” with “what” and “how”:

• What did we know when the decision was made?
• What made this the reasonable choice at that time?
• What would have made the right choice more obvious?
• How did this get to production without being caught?
• What helped us recover, and how do we keep it?

Resist the single root cause. Real incidents usually have several contributing factors: a latent bug, a missing alert, an unclear runbook, a tired team, a deploy at a bad moment. Listing them as contributing factors, rather than hunting one culprit, gives you more places to improve. Techniques like repeatedly asking why can help, but stop when answers turn into generalities.

Also record what went well. Fast escalation, a good rollback, a helpful runbook: protecting those is as important as fixing failures.

Structure of the Written Record

A consistent template makes documents easier to write and compare.

Section	What goes in it
Summary	Two or three sentences on impact and duration, in plain language
Impact	Who was affected and how, using measured data where available
Timeline	Timestamped events including what responders knew
Contributing factors	Multiple technical and process causes, no names as causes
What went well / what didn’t	Short lists
Action items	Specific, owned, with a due date
Lessons	Anything the wider organisation should know

Keep the summary readable by non-engineers. Leadership and adjacent teams will read the top and rarely go further.

Action Items That Actually Get Done

The measure of a postmortem is whether anything changes. Most fail here because the action items are vague (“improve monitoring”), unowned, or competing with the roadmap without priority.

Good action items are concrete and verifiable: “Add an alert on queue depth for the payments worker, owner and date”, not “be more careful”. Distinguish quick mitigations from larger structural fixes, and give both a place in the normal work tracker, not only in the document. Keep the list short. A postmortem that generates twenty items usually completes none; five well-chosen ones tend to get finished.

Review open items regularly. Without follow-up, the document is a diary entry.

A Realistic Example

Consider an incident where a configuration change caused a service to reject most requests for a while. The first draft of the review blames the engineer who deployed it.

The facilitator redirects. The timeline shows the change passed review, but the staging configuration differed from production so the problem could not appear there. Detection took a long time because the alert for error rate was tuned to a threshold the incident never crossed. Recovery was slow because the rollback steps lived in one person’s head.

The action items become: make staging configuration match production for that setting, add an alert tied to the user-facing success ratio, and write and test a rollback runbook. Three items, each with an owner. Nobody was blamed, and the next engineer making a similar change has three more safety nets than before.

Common Mistakes

• Holding the review too late, when memories have faded, or too early, when people are exhausted.
• Skipping minor incidents. Near misses are cheaper lessons than outages.
• Letting senior voices dominate. Ask the quietest responder what they saw.
• Treating “human error” as a conclusion rather than a starting point.
• Never sharing the results, so other teams repeat the same failure.

Frequently Asked Questions

How soon after an incident should the postmortem happen? Soon enough that details are fresh, usually within a few days, but after people have rested. Draft the timeline quickly and hold the discussion once the immediate pressure is over.

Does blameless mean no accountability? No. Accountability shifts from punishing individuals to owning improvements. If someone repeatedly ignores agreed practices, that is a management conversation held separately.

Which incidents deserve a postmortem? Set criteria in advance, such as customer-visible impact, data loss, or a page that needed escalation. Also review near misses with learning value.

Who should attend? Responders, the service owners, and a facilitator. Invite others who can fix contributing factors. Keep the group small enough that everyone speaks.

Should postmortems be shared publicly? Internally, widely. Externally, that is a communications and legal decision for your organisation, and customer-facing summaries are written differently from internal reviews.

Next Step

Pick your most recent significant incident that never got a proper review. Build the timeline from chat and alert history, schedule a thirty-minute discussion with the responders, and leave with no more than five owned action items.