A blameless postmortem is the review after an incident in which nobody gets pilloried, yet every mistake still ends up on the table. That sounds like a contradiction. Even so, it is the tool I would like every team that runs software in production to have. After an outage, the first few minutes decide whether a team learns something or whether everyone starts covering their tracks.
As a team lead, I care about this because the manager’s first reaction sets the tone. Ask “Who did this?” and you will hear less next time. Ask “What made this possible?” and you get an honest picture. In this article you get a seven-step process, questions for the meeting, wording that avoids hidden blame, and a template you can copy.
In short
A blameless postmortem analyzes an incident without looking for culprits and ends with a few binding actions. The key insight: human error is never the cause but the starting point for asking why the mistake was possible. The biggest pitfall is actions that nobody follows up on.
What you will learn in this article
- What “blameless” means and why it does not remove accountability
- When a postmortem is worth it and when it is not
- A seven-step process with a 60-minute agenda
- Questions and wording that avoid assigning blame
- A postmortem template you can use right away
What is a blameless postmortem?
A postmortem (Latin for “after death”) is a structured, written analysis of an incident: What happened, what was the impact, how did the team respond, and what changes so it does not happen again? “Blameless” means free of blame. The analysis assumes that everyone involved did their best based on what they knew at the time. It looks for weaknesses in systems and processes, not for guilty people.
Google made the approach widely known with its Site Reliability Engineering book, and so did Etsy with John Allspaw’s 2012 piece on “just culture”. At Amazon, the counterpart is called “Correction of Error” (COE) and puts even more weight on the actions. The names differ, while the core stays the same: learn from a mistake instead of punishing it.
How it differs from retrospectives and pre-mortems
A retrospective looks at how the team worked together during the sprint, on a regular cadence, even when nothing went wrong. A postmortem, on the other hand, has a specific trigger, namely an incident, and produces a document other teams can read later. The pre-mortem method is the mirror image beforehand: the team imagines a project has already failed and looks for reasons before anything happens. All three formats complement each other, but none replaces another.
Why “blameless” does not mean “without accountability”
The most common objection to a blameless postmortem goes like this: “So nobody has to answer for their mistakes anymore?” The opposite is true. Whoever made the mistake is the most important person in the room, because only they can explain why their decision looked sensible at that moment. Accountability here means disclosing your own view completely and helping to build the fix.
Allspaw calls this the “second story”. The first story is told quickly: someone ran the wrong command. The second story asks why the wrong command was so easy to run, why no check caught it, and why the assumption seemed plausible. Only this second story leads to actions that also work for the next person.
There is also a very practical reason. When mistakes get punished, people quickly learn to leave out details. Then exactly the information you need for a real root cause analysis is missing. That is why a good postmortem is closely tied to psychological safety in the team: both depend on people being able to speak openly without paying for it.
When is a blameless postmortem worth it?
Not every small mistake needs its own document. Otherwise the postmortem turns into bureaucracy and the team only writes mandatory texts. It makes sense to define the triggers in advance, before the next incident happens. For example, the Google SRE book names these criteria:
| Trigger | Example |
|---|---|
| User-visible downtime or significant slowdown above a defined threshold | A ticket shop’s checkout does not respond for 20 minutes |
| Data loss of any kind | A day’s orders are missing from the reports |
| On-call intervention | Rolling back a deployment, rerouting traffic |
| Resolution takes longer than a defined limit | The incident is only fixed after two hours |
| Monitoring failed | Customers report the problem before any alert fires |
In addition, anyone on the team may request a postmortem. Near misses, where only luck prevented damage, are often more instructive than the actual outage. At PagerDuty, for instance, a postmortem is mandatory for all incidents of the two highest severity levels.
Blameless postmortem process in seven steps
The following process is deliberately lean. It works for a single team just as well as for an incident that involved three teams. Order matters: stabilize first, then gather facts, then evaluate.
The process in seven steps: insights flow back into operations.
1. Stabilize first, analyze later
While the incident is ongoing, nobody digs for causes; the job is to limit the damage. The analysis starts once operations are stable again. Still, it helps to take notes during the incident: who saw and did what, and when? A dedicated chat channel per incident produces these notes almost automatically.
Who coordinates the incident itself and how the roles are split is covered in my guide Incident Commander Role: A Guide for Small Teams.
2. Assign an owner and set a date
Right after the incident, one person takes ownership of the postmortem. They gather data, write the draft, and send the invitations. This does not have to be the person who triggered the mistake, nor the manager. Ideally, you set the date immediately while memories are fresh. PagerDuty, for example, schedules the meeting within three calendar days for the most severe incidents and within five business days for the next level.
3. Build a timeline from facts
The timeline is the heart of the document. It does not start with the first alert but with the actual trigger, for example the deployment or the configuration change. Each entry gets a timestamp in one consistent time zone and a piece of evidence, such as a link to a metric, a log query, or a chat message. Gaps longer than ten to fifteen minutes deserve an explanation. AWS recommends this for the COE format, and it often reveals exactly where the team did not know what was going on.
4. Facilitate the meeting
Send the draft about a day in advance so everyone can read it and add to it. For the meeting itself, 30 to 60 minutes is usually enough. This agenda has proven useful:
- Opening (5 minutes): State the goal and ground rules. One sentence is enough: “Today we are looking for gaps in the system, not for culprits.”
- Walk through the timeline (15 minutes): Participants add what they saw, expected, and assumed.
- Causes and contributing factors (15 minutes): Why was the mistake possible, and why was it not noticed earlier?
- Actions (15 minutes): Pick a few actions, prioritize them, and agree on owners and dates.
- Wrap-up (5 minutes): Collect open questions and clarify next steps and the distribution list.
Ideally, the facilitator is someone who was not deeply involved in the incident. That way they can pay attention to the language and step in when a question turns into an accusation.
5. Analyze causes instead of finding culprits
A proven technique is the “5 whys”: you start with the problem and keep asking “Why?” until the chain of causes is clear. That may take more or fewer than five questions. If an answer lands on “human error”, this is where the analysis really begins: Why was this mistake possible, and why did nothing catch it?
A fictional example from a ticket shop: order confirmations arrive 47 minutes late. Why? The shipping queue filled up. Why? The worker crashed on every message. Why? A new environment variable was missing in production. Why? It had only been set by hand in the test environment. Why was that possible? Nothing checked whether required variables exist during deployment. So the action is an automated check in the deployment, not a reminder to be more careful.
Also keep in mind that incidents rarely have exactly one cause. Usually several contributing factors come together, for example a missing alert, confusing documentation, and a deployment shortly before the end of the day. Write them all down, even if you do not derive an action for each one.
6. Few actions, but binding ones
Every action needs an owner, a priority, and a date. According to AWS, COEs average six to eight actions. For a single team, I would rather start with three that actually get done. A good rule of thumb is the question from the COE format: What would have to happen to cut the time to detect, the time to diagnose, and the time to mitigate in half? This often produces better actions than root cause analysis alone.
7. Share and follow up
A postmortem that disappears into a folder has missed its purpose. The Google SRE book puts it plainly: “An unreviewed postmortem might as well never have existed.” Store the documents in a fixed place where every team can find them, and remove customers’ personal data along the way. The actions belong in the backlog as tickets. Review them again in the next retrospective or in a fixed monthly slot.
Questions for the postmortem meeting
The right questions make the difference between an interrogation and an analysis. Etsy recommends that participants describe which actions they took and when, what they observed and expected, and why their approach made sense at the time. Based on that, I put together this list of questions:
About the sequence of events
- What did you see at that moment, and where did the information come from?
- What did you expect to happen next?
- Which assumption turned out to be wrong in hindsight?
- What put you under pressure when you made the decision?
About detection and resolution
- How did we learn about the incident: from an alert or from customers?
- Which piece of information would have sped up the diagnosis considerably?
- What worked well during the fix and should stay that way?
- Where did we have to improvise because no runbook existed?
About the causes
- What made this mistake possible in the first place?
- Why did no automated check fire?
- Where else could the same mistake happen, for example in other services?
Wording that avoids blame
Blame often hides in small words. Hindsight bias is especially tricky: afterwards it is obvious what would have been right, so sentences with “should have” and “just” sound reasonable. For the person who had to decide at that moment, however, the situation was not obvious. This comparison helps with writing and facilitating:
| Instead of | Better |
|---|---|
| “Anna forgot the variable.” | “The variable was only set in the test environment; the deployment does not check required variables.” |
| “Someone should have seen that.” | “Which signal was there, and why did nobody notice it?” |
| “He just ran the wrong command.” | “The command for production and test differs in only one parameter.” |
| “Why didn’t you wait?” | “What spoke for acting immediately?” |
| “Human failure” as the cause | “Human error” as the starting point for the next why |
Names belong in the timeline, because that is where you record who did what. In the cause analysis and the actions, however, they have no place. It also pays to use words like “outage” sparingly. PagerDuty, for example, recommends using it only for a true full outage and otherwise speaking of an incident or degradation.
Blameless postmortem template
You can copy this template straight into your wiki, a Markdown document, or a ticket. It follows the sections of the AWS COE format and the Google SRE book. Write the summary last, but keep it at the top so busy readers know the essentials after three sentences.
# Postmortem: <short title of the incident>
Status: Draft | In review | Closed
Owner: <name> Facilitator: <name>
Date of incident: <YYYY-MM-DD> Meeting: <YYYY-MM-DD>
## Summary (write last)
What happened, who was affected, for how long, how was it fixed,
and what changes? Five sentences at most.
## Impact
- Affected users or systems:
- Duration (start to normal operations):
- Measurable effects (error rate, delayed operations, data loss):
## Timeline (one time zone, every entry with evidence)
| Time | Event | Evidence |
|-------|-------|----------|
| 14:02 | Deployment of shipping worker version 1.8 | Pipeline link |
| 14:05 | Worker error rate rises to 100 % | Metric link |
| 14:31 | Customer report reaches support | Ticket link |
## Detection, diagnosis, mitigation
- How did we notice? What would have cut detection time in half?
- What delayed the diagnosis? What would have cut it in half?
- What helped with the fix? What would have cut it in half?
## Causes and contributing factors
- Chain of whys (5 whys):
- Other contributing factors:
## What went well
-
## Actions
| Action | Priority | Owner | Due | Ticket |
|--------|----------|-------|-----|--------|
| | | | | |
## Open questions and related documents
-
At first glance, the “What went well” section looks cosmetic. I consider it important because it shows which habits the team should keep. It also changes the mood in the room: a postmortem then feels less like a tribunal.
Common postmortem mistakes
The manager looks for someone to blame
A single sentence like “This must never happen again, who was it?” is enough, and the team understands what this is really about. If you lead a team, you are therefore the most important person for the culture, even if you barely speak in the meeting. Atlassian has good reason to recommend getting executive support before introducing the practice.
Too many actions without owners
A list of twelve items looks thorough but rarely gets done. A few actions with names and dates work better. Anything that will not be done should be explicitly dropped rather than quietly going stale.
Only writing one when it really hurt
If you only write postmortems for major disasters, you never practice the format calmly. Smaller incidents and near misses are perfect for rehearsing the process. Moreover, the barrier drops once a postmortem is something normal.
“More care” as an action
“We need to pay closer attention” sounds sensible but changes nothing. Good actions change the system: an automated check, a better alert, a runbook, a guard against accidental commands in production.
My take
For me, the blameless postmortem is less a method than a test of leadership. The template takes ten minutes to set up. What is hard is staying calm when customers complain and your own boss asks how this could happen. That is exactly when you find out whether “blameless” only exists on a slide.
Where I disagree: blameless does not mean without consequences. If someone repeatedly and deliberately bypasses rules, that is a topic for a one-on-one, not for the postmortem. Mixing the two costs you openness in the team. I also see AI assistants as a useful help with the draft these days: they can build a first timeline from a chat history. You still have to verify it against metrics and logs, because an assistant only knows what was said in the chat, not what happened in the system.
By the way, you do not have to wait for a real outage to practise postmortems. I show how to set up a planned practice incident for a Lambda service in AWS FIS Lambda: chaos experiments step by step.
FAQ
What is the difference between a postmortem and a retrospective?
A retrospective takes place regularly and looks at collaboration during the sprint. A postmortem has a specific trigger, usually an incident, and produces a written document with a timeline, causes, and actions.
Who should attend the postmortem?
The people who were involved in the fix, the owners of the affected services, and the engineering manager or product manager. If needed, other teams such as security or support join as well.
How soon after an incident should the postmortem take place?
Ideally within a few days, while memories are fresh. PagerDuty, for example, plans three calendar days for the most severe incidents and five business days for the next level.
Can a blameless postmortem mention names?
Yes, in the timeline, because that is where you record who did what. Causes and actions, on the other hand, are about systems and processes, not people.
Your next step
Spend 20 minutes with your team agreeing on when you write a postmortem, and save the template above in your wiki. Then take your last smaller incident and walk through the process once, without any pressure. That way the format sits when it really matters.
I am curious: How does leadership around you react to incidents, and what helped your team talk about mistakes more honestly? Let me know in the comments.
Sources
- Google: Site Reliability Engineering, chapter 15 “Postmortem Culture: Learning from Failure”
- John Allspaw (Etsy): Blameless PostMortems and a Just Culture (May 22, 2012)
- AWS Cloud Operations Blog: Why you should develop a correction of error (COE) (February 18, 2022)
- PagerDuty Incident Response Documentation: Postmortem Process
- Atlassian: How to run a blameless postmortem
This post was created with AI assistance.
👉 Next step: Not sure which AWS service fits your use case? My AWS service finder asks a few questions and points you to the right one.
Originally published on sascha-ms.de. More articles on serverless, AI in everyday development and leading tech teams: sascha-ms.de/en
Top comments (1)
Your note on using an assistant for the first draft matches something I tried. I gave one made-up set of incident notes to HelloAI twice (I do marketing for it). Asked plainly for a blameless postmortem, it copied the stated 37-minute impact straight in, although the timestamps only give 33 minutes from deploy to recovery (25 from first errors). It also kept "alert fired late because the threshold was 15%" even though the error rate was 12%. Asked to check the notes for inconsistencies first, it flagged both.
That was one run each on notes I wrote, so I wouldn't read more into it than that. But it suggests a cheap line for the template next to "Duration (start to normal operations)": say which two timestamps it was computed from. Write-up with both prompts: dev.to/mercerk17/same-incident-not...