How to Write a Blameless Postmortem in Under 20 Minutes

The postmortem you were supposed to write last Tuesday is still open in a tab. It is going to take 4 hours. You already know because the last one took 6, and this one is the same problem: reconstructing what happened from Slack scrollback, cross-referencing dashboard screenshots, and asking three responders "what were you doing at 14:22?"

That is the wrong problem to be solving on a Tuesday afternoon. Here is what a 20-minute postmortem looks like.

What does a 20-minute postmortem require?

Two preconditions. Get either one wrong and the timeline explodes back to 4 hours.

• The incident timeline was captured live. Every alert, decision, hypothesis, and action was recorded in a single timeline during the response, not reconstructed after. If your incident tooling generates the timeline automatically from Slack messages and monitoring events, you already have this. If not, the scribe role must be enforced during every SEV2 and SEV1.
• The template is thin and non-negotiable. Six sections. No optional fields. No "additional context" section that turns into an essay. The template is the same for every incident, so writers do not spend time deciding what to include.

If both conditions are met, the postmortem is a 20-minute edit and review, not a writing project.

What are the six sections of a working postmortem template?

Each section has a defined output and a length target.

Sections that do not appear on this list: "root cause" (see below), "lessons learned" (redundant with contributing factors), "acknowledgements" (belongs in Slack, not the postmortem).

What language rules make it blameless?

Three rules, applied ruthlessly during the review.

• Describe systems, not people. "The deploy pipeline pushed the change to production without running the smoke test" is fine. "Alex pushed the change without running the smoke test" is not. Even when a person did make the choice, the postmortem describes the conditions that led to the choice, not the choice as a personal failing.
• No modal verbs of judgment. Cut "should have," "could have," "failed to," "neglected to." Replace with "did not," which is a statement of fact rather than a statement of moral fault.
• Preserve the temporal viewpoint. Describe what the responders knew at the time, not what you know now. "The team believed the database was healthy based on the dashboard, which was showing stale metrics" is blameless. "The team wrongly believed the database was healthy" is not, because it evaluates a past belief against present information.

The reviewer's job is to enforce these rules. If the involved team wrote the first draft, they will have missed at least three violations because the language feels natural to them.

How do you write the summary in 3 sentences?

The summary answers four questions. Compress each to one clause.

• What system was affected and how (one clause)
• Who was affected and for how long (one clause)
• What was the root fix (one clause)
• What is the followup posture (one clause, optional if obvious)

Example: "The checkout API returned 5xx for 14% of requests over 47 minutes, driven by database connection pool exhaustion after a config change. The team resolved by rolling back the change and increasing pool size; monitoring is now in place for connection pool saturation."

Four clauses. Three sentences. Written from the timeline in about two minutes.

Why should you avoid the "root cause" section?

Because there is almost never one. Systems fail when multiple contributing factors align: a code change plus a monitoring gap plus a runbook that was stale plus an alert that fired late. Naming one of those as "the root cause" implicitly downgrades the others, which are the ones your team will get bitten by again next quarter.

Replace "root cause" with "contributing factors," ranked by leverage. Ask "if this factor had been different, would the incident have happened?" A factor that changes the answer to no is a top contributor. A factor that only made the incident worse or longer is a secondary contributor.

A good contributing factors section reads like this:

1. The config change was deployed without a canary rollout because canary was disabled for this service after a prior flake.
2. The database connection pool did not have a saturation alarm; alerting relied on end-user error rate.
3. The runbook for connection pool exhaustion referred to a monitoring dashboard that had been renamed 4 months earlier.

Each item is a system fact. Each is fixable. None names a person.

How do you make action items actually happen?

Every action item needs three things, in the postmortem itself:

• Named owner. Not a team. A person.
• Due date. Real, not "next quarter."
• Ticket link. Jira, Linear, or GitHub Issues. The item exists in your team's normal workflow.

Then close the loop with a weekly action item review, reported to the head of engineering. Items overdue by more than a week get escalated. Items overdue by three weeks get either closed as "will not do" (with an explanation) or reassigned.

The rule of thumb: if a postmortem has 8 action items and no owners, you will complete 1 to 2 of them. If it has 3 items with owners and due dates, you will complete 3.

When should you run the postmortem review meeting?

Within 5 business days of resolution. Any longer and the responders have forgotten the details. Any shorter and the emotional charge is still too high for a productive conversation.

• Attendees. Incident commander, primary responders, engineering manager of the affected service, an SRE from an adjacent team.
• Length. 45 minutes. If it needs longer, split it: 30 minutes on the incident, 15 minutes on the action items, additional meetings only for contested items.
• Output. The published postmortem, the closed action item tickets, and one runbook edit.

The meeting is not for writing the postmortem. That work is done before. The meeting is for pressure-testing the contributing factors, prioritizing action items, and enforcing the language rules.

The mistake to avoid

Teams treat postmortems as a writing task and complain about how long they take. The writing is not the hard part. The hard part is the timeline capture, which happens during the incident, when everyone is busy fixing the problem. Move the timeline capture from a human scribe to automation, and the postmortem drops from 6 hours to 20 minutes without anyone getting a better writer. The document was never the bottleneck.