How to run an incident postmortem review without blame

What the postmortem review is for

Google's Site Reliability Engineering book defines a postmortem as a written record of an incident. It covers the impact, the actions taken to mitigate it, the root causes and the follow-up actions to prevent it happening again.

The review meeting finalizes that record. Close open comments and discussions, agree on the action items and decide who should read the result. Google's SRE teams put it bluntly: an unreviewed postmortem might as well never have existed.

How it differs from a retrospective

A sprint retrospective looks at how the team worked over a sprint. A postmortem looks at one incident in depth, often across teams, and produces a document others will read and learn from.

If an incident surfaces in your retro, schedule a separate postmortem rather than squeezing it into the retro's timebox.

Decide when to hold one

Agree on the triggers before an incident happens, so nobody has to argue for a postmortem afterwards. Google lists these common triggers:

• User-visible downtime or degradation beyond a threshold.
• Data loss of any kind.
• An on-call engineer had to intervene, for example with a rollback or rerouting traffic.
• Resolution took longer than a threshold.
• Monitoring failed, so the incident was found by hand.

What to bring

Circulate a draft before the meeting, so the time goes to decisions rather than reading. The draft should hold:

• A timeline of what happened and when, linked to the incident log.
• The impact on users and systems.
• Contributing causes, traced as deep as the team can take them.
• Proposed action items, each with a draft owner and priority.

Keep the discussion blameless

A blameless postmortem looks for contributing causes without accusing any person or team. It assumes everyone acted with good intentions on the information they had.

Ask why the system let a mistake happen, not who made it. In practice, rewrite "Sam pushed a bad config" as "the config change reached production without a validation check".

Write action items that get done

Google's SRE workbook reviews a weak postmortem and a strong one. The strong version's action items share four traits:

• One owner each, plus a tracking ticket.
• A priority, so the team knows what to tackle first.
• A verifiable end state, such as "add an alert when more than X% of machines are removed", not "improve monitoring".
• Preventive fixes as well as mitigations, favoring changes to systems over asking people to be more careful.

A sample 45-minute agenda

Adjust the times to the size of the incident:

• 5 minutes: restate the impact and confirm the timeline.
• 15 minutes: walk the contributing causes and resolve open comments.
• 15 minutes: agree on action items, owners and priorities.
• 5 minutes: check the review questions. Was key data collected, is the impact complete and is the root cause deep enough?
• 5 minutes: decide who else should read it, and where it will be stored.

Running the review in Bridge

Host the review on Bridge, or capture it on Zoom, Google Meet or Teams with Bridge Agent. You get a speaker-labeled transcript and structured notes afterwards, so agreed owners and priorities are on record.

Keep every postmortem review in one space and share it with your engineers. Everyone with access to the space can open every meeting in it, so people who join later can read past incidents without asking for links.