In this article
Before you start
This page is one part of the site reliability engineer interview guide, and the DevOps interview learning path covers the background.
Why interviewers ask this
A question about blameless postmortems tells an interviewer whether you would make a team safer or quieter after something breaks. Candidates report it in site reliability and DevOps loops, often as "tell me about a postmortem you took part in" or as a short definition question.
A weak answer says "we don't blame anyone" and stops, which sounds like no accountability. Another weak answer names a culprit and calls it a lesson. A strong answer shows that you can describe exactly what happened, find the conditions that made it possible, and leave behind fixes with owners. A Staff-level answer adds the failure mode of the process itself: action items that are written down and never finished.
Blameless postmortem from first principles
- Contributing cause
- A contributing cause is a condition, such as a missing check, a confusing tool or a gap in monitoring, that together with others allowed an incident to happen or made it worse, which is why a review looks for causes in the plural rather than for one culprit.
- Action item
- An action item is a specific follow-up task from a postmortem that has an owner and a due date and is tracked until it is finished, so that the review changes the system instead of only describing it.
In plain words
Think of a pilot error report. The point of the report is that the next pilot, in the same cockpit, should not meet the same trap. Naming and shaming the last pilot changes nothing about the cockpit. The analogy breaks in one place: in software the "cockpit" is code, tools and process, so the fix is usually something you can ship or change.
A postmortem is a written record of an incident. As Google's Site Reliability Engineering (SRE) book defines it, the record covers the impact, the actions taken to resolve it, the root causes and the follow-up actions that prevent a repeat. The book calls blameless postmortems a tenet of SRE culture. It says blameless culture began in healthcare and avionics. John Allspaw popularised the practice for software in a 2012 essay at Etsy, which the chapter cites.
In one precise sentence, a blameless postmortem replaces the question "who failed?" with "why did a person or team have incomplete or incorrect information?"
Step 1: Build the timeline forward
The timeline of a blameless postmortem starts before the incident and moves forward in time. Starting early and moving forward avoids hindsight bias. Hindsight bias is the habit of judging past decisions by an outcome that the people involved could not yet see.
Input: logs, chat history, alerts and the memories of the responders; the difference between monitoring, logging and tracing shows where each kind of evidence comes from. Output: an ordered list of events with times, each stating what was known at that moment. When you write "the engineer pushed the change at the start of the incident", you also write what the change looked like to that engineer: the review it passed and the checks that stayed green. Working backwards from the outage makes every earlier decision look careless; working forwards shows why each decision looked reasonable.
You now know where the facts come from; the next step says how to describe them.
Step 2: Name the actions and keep accountability
A blameless postmortem names the actions that led to the incident and still blames no one. Google's text says a blamelessly written postmortem "assumes that everyone involved in an incident had good intentions and did the right thing with the information they had" (Google, SRE book). That sentence is the answer to the follow-up from the lead.
Blameless is not silent. A good review states plainly which actions led to the incident and where the service must improve. "A config change was pushed without validation" is a fact. "The engineer was careless" is a judgement about a person.
Accountability moves from punishment to ownership. The person closest to the event often knows the most about how the system misled them, so they are the best teacher for everyone else. Input: the forward timeline. Output: plain statements of what happened and what each person knew.
Step 3: Find the contributing causes
Contributing causes are the system conditions that let one action become an incident. Google's book puts the principle in one line: "You can't "fix" people, but you can fix systems and processes" (Google, SRE book). A person's error is therefore where the analysis starts, not where it ends: someone acting on the information they had points to a condition that let the error through.
So after "who pushed the change" you keep asking why. Why did validation not exist? Why did the change reach every server together? Why did the alert take minutes to fire? Each answer is a contributing cause with a possible fix. Google's review checklist asks whether the root cause was "sufficiently deep", which is the same test: if the last "why" still names a person, the analysis stopped too early.
Input: the named actions. Output: a short list of conditions, each fixable.
Step 4: Turn causes into tracked action items
Action items are what make a postmortem change the system. Google states that "an unreviewed postmortem might as well never have existed", and its review checklist asks whether the action plan is appropriate and whether resulting bug fixes have a fitting priority (Google, SRE book).
Each action item needs an owner, a due date and a type: prevent a repeat, detect it sooner, or reduce its impact. There is a real gap to watch. PagerDuty's process page says the postmortem owner creates the follow-up tickets but is only responsible for creating them, not following them to resolution. Strong teams name who closes the loop.
Templates vary by team; a common layout is a summary, impact, timeline, causes, resolution, action items and lessons learned.
You now have the whole method: forward timeline, named actions, contributing causes, owned fixes.
Step-by-step description
- Build the timeline forward.
- Name actions, not blame.
- Find contributing causes.
- Track owned action items.
- The timeline starts before the incident and runs forward.
- Every action item has an owner and is tracked until it is done.
The timeline starts before the incident and runs forward. Every action item has an owner and is tracked until it is done.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
This hypothetical incident is invented for the walkthrough; no real company is described. A configuration push at minute 0 makes a service return errors. The service handles 3,000 requests a minute and 40% of them fail while the bad setting is live (both numbers illustrative). The first alert fires at minute 3, the on-call engineer acknowledges at minute 5, a rollback starts at minute 9 and errors end at minute 12.1
Detection took 3 minutes and errors ended at minute 12. The service handled 36,000 requests in those 12 minutes and 14,400 of them failed, at 1,200 failed requests a minute.1 The failures split by phase: 3,600 before the first alert (25% of the total), 7,200 between the alert and the start of the rollback (50%) and 3,600 during the rollback (25%).1 A blame-focused review stops at "the engineer pushed a bad setting". A blameless review sees that half the damage happened between the first alert and the start of the rollback, and three quarters of it after the alert (10,800 of 14,400 failed requests), so the contributing causes include slow diagnosis and a rollback that needed several manual steps.
| Quantity | Value (computed from illustrative inputs) |
|---|---|
| Requests handled during the incident | 36,000 |
| Failed requests | 14,400 |
| Failed before the first alert | 3,600 |
| Failed from alert to rollback start | 7,200 |
| Failed during the rollback | 3,600 |
| Action items (2 prevent, 1 detect, 1 reduce impact) | 4 |
| Action items with an owner | 4 |
| Latest due date, days after the review | 30 |
| Failed requests if the bad setting reached only 5% of traffic for the same 12 minutes (illustrative) | 720 |
The four action items are: add validation to the push pipeline (owner: platform team, due in 14 days), roll settings out to 5% of traffic first (owner: release team, due in 30 days), alert on the error rate within a minute (owner: on-call team, due in 21 days) and write a one-command rollback runbook (owner: service team, due in 7 days).1 Each addresses a contributing cause, and none says "be more careful".
Text description of the diagram
- Detection took 3 minutes and errors ended at minute 12.
- The first alert fires at minute 3 and a rollback starts at minute 9.
Trade-offs and edge cases
Blameless review trades speed of judgement for quality of learning. Blame feels faster: one name, one lesson. But blame makes people hide issues, so the organisation loses information; removing blame lets people escalate without fear (Google, SRE book). Blameless review costs time and effort, so Google's chapter advises being deliberate about when to write one.
Etsy's 2016 debriefing guide asks facilitators to draw out the cues, context and rationales behind each decision. Telling a person to try harder does the opposite: it asks for more effort and leaves the system as it was.
Text description of the diagram
- Blame makes people hide issues.
- Blameless review asks why a person had incomplete information.
Blame makes people hide issues. Blameless review asks why a person had incomplete information.
Edge cases. First, triggers: Google says to define postmortem criteria before an incident, such as user-visible downtime beyond a threshold, data loss, on-call intervention or a monitoring failure, and it leaves the thresholds to each team. Second, size: as of October 2026, PagerDuty recommends a postmortem for every major incident and also runs one for false alarms, so a postmortem is not only for big outages. Third, reputation: do not stigmatise people or teams who write many postmortems, or people stop writing them. Fourth, timing: PagerDuty's internal policy is to complete the postmortem within 3 calendar days of a severity 1 (Sev-1) incident and 5 business days of a severity 2 (Sev-2) incident, as of October 2026 (PagerDuty).
How to answer it in an interview
What is a blameless postmortem, and how would you run one?
A blameless postmortem is a written review of an incident that asks why the system let a reasonable person make that move, not who to punish. I build the timeline forward from before the incident, name exactly what happened, including who pushed the change, and list the contributing causes. Then I turn them into action items with an owner and a date, and I check them later, because a postmortem nobody reviews changes nothing. Blameless does not mean unaccountable: the person who erred often teaches the fix.
The spoken structure: define it in one sentence, say the timeline and the facts are still specific, give the causes, finish with owned action items and the review.
When the question is behavioural, such as "tell me about a postmortem you took part in" or "tell me about an outage you caused", use the situation, task, action, result (STAR) shape. The answer below is a composite built on the worked example, not a real case.
Common mistakes
- "Blameless means nobody is accountable." (wrong) A blameless review still states what happened and what must change. (right) "Accountability moves from blame to owning the fix."
- "Blameless means we don't say who did what." (wrong) The format identifies the actions that led to the incident. (right) "We name the actions and the information people had, not their character."
- "The root cause was an engineer's mistake." (wrong) Human error is a symptom of a systemic problem. (right) "The cause was that nothing validated the change."
- "Postmortems are only for big outages." (wrong) They are a learning opportunity, and they are also run on false alarms. (right) "Postmortem criteria are agreed before an incident."
- "We wrote the document, so we are done." (wrong) An unreviewed postmortem might as well never have existed. (right) "We track the action items to completion."
Follow-up questions
Does blameless mean nobody is accountable?
No. The review still names the actions that led to the incident and the fixes needed. Accountability becomes ownership of action items and of helping the organisation get safer, instead of punishment for a mistake.
Is a blameless postmortem the same as finding the root cause?
Not quite. Google writes about contributing causes and root causes in the plural, and says you can fix systems and processes, not people. The aim is every condition that let the incident happen, kept going until the last answer is something you can change.
When should you write a postmortem?
Agree the criteria before an incident. Google lists downtime or degradation beyond a threshold, data loss, on-call intervention and a monitoring failure, and any stakeholder may request one. See the incident response scenario answer for the live-incident side.
Can you tell me about a time you took part in a postmortem?
Use the situation, task, action, result (STAR) shape as your own structure: the incident, your role, what the review found and the action items that shipped. Say what you changed, never who was at fault. Only describe a real case; the hypothetical above is a model, not a story to reuse.
How do you make sure action items get done?
Give each one an owner and a due date, review them in a regular meeting and name one person who closes the loop. PagerDuty's process page shows the gap: the owner creates tickets but is not responsible for following them up. The site reliability guide places this inside the wider role.
- A blameless postmortem is a written incident review that seeks contributing causes, not a culprit.
- Build the timeline forward from before the incident to avoid hindsight bias.
- Name the actions plainly; accountability becomes ownership of fixes.
- Action items need an owner, a due date and a review, or the postmortem changes nothing.
- In an interview, define it, show specifics, and end on tracked action items.
Sources
- Postmortem Culture: Learning from Failure (Site Reliability Engineering, chapter 15) — Google (O'Reilly), 1 Jan 2016
- Blameless PostMortems and a Just Culture — Etsy Code as Craft (John Allspaw), 22 May 2012
- Debriefing Facilitation Guide: Leading Groups at Etsy to Learn From Accidents — Etsy (Allspaw, Evans, Schauenberg), 1 Jan 2016
- Postmortem documentation: what is a postmortem and how to write one — PagerDuty, 1 Jan 2026
- Postmortem Process — PagerDuty Incident Response Documentation, 1 Jan 2020
