How to Write a Blameless Postmortem People Actually Read

After an outage, a missed launch, or a data mistake, someone has to write down what happened. The postmortem is that document. Its purpose is to stop the same thing happening again, and it only works if the people involved are honest about what they did, which only happens if they trust the document will not be used against them.

That is what “blameless” means. It does not mean nobody is accountable. It means the document looks for causes in systems, processes, and conditions rather than in a person’s character. The idea is laid out well in the postmortem culture chapter of Google’s Site Reliability Engineering book.

Use A Structure Readers Can Skim

Most postmortems are read by people who were not there and have five minutes. Put the summary first and keep the sections predictable:

1. Summary. Two or three sentences: what broke, for how long, who was affected.
2. Impact. Numbers where you have them: duration, users affected, revenue or data affected.
3. Timeline. Times and events, written neutrally.
4. Contributing factors. Usually several, rarely one.
5. What went well. Detection, response, communication that worked.
6. Action items. Each with an owner and a date.

If your team writes general incident reports for non-technical audiences, how to write an incident report at work covers the shorter, broader version.

Write The Timeline Without Adjectives

The timeline is where blame sneaks back in. Words like “accidentally”, “carelessly”, “failed to”, and “should have” turn a factual record into a judgment.

Before:

14:02 Dan carelessly pushed the config change to production without testing it, which took down checkout.

After:

14:02 A configuration change was deployed to production. The deploy pipeline did not run the checkout integration tests for configuration-only changes.

14:06 Checkout error rate rose above 40%. The on-call engineer was paged.

The second version is more useful, not just kinder. It points at the real problem: the pipeline allowed an untested change, which means it will happen again with someone else.

Ask “How”, Not “Who”

When you write the contributing factors, frame each one as a condition that made the error possible or likely:

• The runbook described a step that no longer existed.
• Two alerts fired for the same symptom, and the more important one was lower in the list.
• The change was made at the end of a long shift because the only person with access was on call.

Each of these suggests an action. “Dan made a mistake” suggests nothing except that Dan will be more nervous next time.

Make Action Items Specific And Owned

The most common postmortem failure is a list of action items that never get done. Keep them few, specific, and assigned.

Before:

Improve testing. Be more careful with config changes. Review monitoring.

After:

1. Run checkout integration tests for configuration changes in the deploy pipeline. Owner: Platform team. Due: 30 October.

2. Merge the two checkout error alerts into one with a clear title. Owner: Aisha. Due: 23 October.

If an action item cannot be assigned to a person or team with a date, it is a wish, and it should be labeled as one or removed.

Share It, Then Revisit It

Publish the postmortem where the wider team can read it. Then put a reminder on the calendar to check the action items in a month. Closing the loop is what builds trust in the process. A project retrospective uses a similar rhythm for planned work rather than incidents.

A Context For Neutral Incident Writing

Rewriting a first draft into blameless language is exactly the kind of editing a rewriter handles well, as long as it does not touch the facts.

A Wrivio Context for postmortems could say:

Rewrite this incident text in neutral, blameless language. Describe actions and system conditions, not personal qualities. Remove words such as “carelessly”, “failed to”, and “should have”. Keep every timestamp, metric, system name, and person’s role exactly as written. Do not change the order of events, remove facts, or add causes that are not in the draft.

Press Ctrl+Shift+Space, paste the timeline, and review the diff. The risk to watch is softening that removes information: “the change was not tested” must not become “the change was deployed”, because the missing test is the finding.

Common Questions

What does blameless mean in a postmortem?

It means the document explains what happened in terms of systems, processes, and conditions rather than personal fault. People are still accountable for follow-up actions, but nobody is punished for being honest about their part.

How soon after an incident should a postmortem be written?

Start the draft within a day or two while details are fresh, and aim to publish within a week. A timeline written a month later is usually missing the details that matter most.

Should a postmortem name the people involved?

Roles are usually more useful than names, such as “the on-call engineer”. Names can appear where they help coordination, but never as the subject of a sentence about fault.

How many action items should a postmortem have?

Usually three to five. Each one needs an owner and a date, and the list should be reviewed about a month later to confirm the work was done.

Download Wrivio for Windows to rewrite a raw incident timeline into neutral, blameless language without changing a single timestamp.