Blameless Postmortem
Practice
A way of reviewing an incident that looks for the structure which let the mistake through instead of the person who made it.
Why it exists
For a long time the first question after an outage was who did it. Narrowing the cause to one person makes the fix look simple: have a word with them, agree everyone will be more careful, close the meeting. The notes record a line about additional training, and a few months later the same outage happens again.
The real damage starts after that. Anyone who has watched a colleague get called out writes less precisely the next time. "Changed a setting" goes into the record instead of which setting and which button, and a record like that never reveals why the setting could be changed without review in the first place. The cost of blame is that the person closest to the incident stops talking.
Pagedeck learned this once. A Friday evening deploy blocked document saves for thirty minutes, and at Monday's review Theo said he had touched the wrong setting, which ended the discussion. Only two months later, when someone else touched the same setting the same way and produced the same outage, did anyone put it on the agenda that the setting had neither a review step nor an undo button.
How it runs
It starts by taking the names out and putting the clock in. Write down what happened minute by minute, then walk back up that line to the points where a judgment call was made. The sequence usually has five steps.
- Build the timeline. Deploy time, first error in the logs, time the alert fired, time a human noticed, time service came back — all to the minute. If errors started at 21:04 and the on-call engineer noticed at 21:38, those 34 minutes are half the incident.
- Reconstruct what each person could see at each of those moments. A cause that looks obvious now may not have been on anyone's screen then. This step exists to keep the review from judging the past with knowledge of how it turned out.
- Ask why the action made sense at the time. If no answer comes, step 2 is usually incomplete. This question differs from "why did you do that" because it doesn't put the person in the position of defending themselves.
- Go down into root cause analysis, which looks past the symptom for the condition behind it. Don't stop at "the wrong setting was changed" — ask why that setting could change without review, and why nothing alerted the moment it did.
- Write action items: follow-ups with an owner and a due date. The wording decides whether they work. "We'll be more careful" leans on human attention and stops nothing. An approval step on setting changes is the other kind — the kind that holds even when someone makes the same mistake again.
Who joins and when
Everyone who took part in the response comes: the on-call engineer, whoever deployed, whoever joined after being paged, and the people who fielded customer messages. Facilitation goes to someone who was not involved. A facilitator who was in the incident spends the session explaining their own calls, and the record tilts that far.
Whether anyone with authority over performance reviews sits in the room changes the outcome more than any rule on the agenda. If people sense the session could feed an evaluation, they speak defensively no matter what was promised. When a founder or a manager does need to attend, agree in advance which parts they are there only to listen to.
Timing is a few days after recovery, not right after it. Ask someone who was up all night to review the night and fatigue talks before memory does. Wait longer than two weeks and the feel of the screens and logs is gone, leaving a vague record. Three to five days out works, with everyone adding what they remember to the document beforehand so the session starts from a shared draft rather than a blank page.
The finished record shouldn't stay with the people who were there. Open it to the whole company and other teams start finding the same conditions on their own side. That only works if no person's name appears in it as the subject of a mistake.
How it sounds at work
"This isn't Theo's fault. The problem is that the setting can change without review."
Moving the cause from a person to a condition.
"No blame today. Write down everything you clicked, as well as you remember it."
Guaranteeing safety first, in order to get an accurate record.
"'Be more careful' isn't an action item. Write something that holds when nobody is careful."
Only structural fixes count as follow-ups, not appeals to attention.
After the second identical outage, Pagedeck changed how the session ran. Grace opened by saying that nothing said in the room would be used in a review, and facilitation went to Mia, who had been on vacation that week. When Theo pulled up the settings screen and shared it, the reason for the mistake was immediately visible: the production and staging screens differed by one word and were otherwise the same color.
Three action items came out of it — change the background color of the production screen, require a second person's approval on setting changes, and fire an alert the moment one changes. All three fix a screen or a procedure rather than a person's attention, and the outage hasn't returned.
What people get wrong
The most common reading is that nobody is held responsible for anything. The word "blameless" invites it. But what the practice removes is individual punishment, not accountability. Every improvement in the document carries an owner and a due date, and the next review checks whether those items shipped. When follow-ups don't fill the space punishment used to occupy, the session becomes a round of reassurance and the same incident comes back next quarter. A team that closes two of three action items within the month is running the practice; a team with forty open items from last year is holding meetings about incidents.
The other frequent mistake is assuming good intentions are enough — that a sentence at the top of the meeting about not blaming each other does the job. In practice the outcome depends on who facilitates, whether the document template makes people the subject of the sentence, and how much psychological safety the team has built up on ordinary days. On a team where admitting a mistake has cost people before, a one-day promise of safety convinces nobody, and the record fills up with vague sentences again.
Where to go next
- Incident management
see where this review sits in the life of a single incident
- Postmortem
see what document the session leaves behind
- Psychological safety
see what has to exist beforehand for any of this to work
Last updated 2026-09-16