Blameless postmortems: a template and how to run the review

A postmortem is the written record of an incident. It explains what happened, why it made sense at the time, and what will change. Incident response basics lists what a useful postmortem contains. This guide covers blameless practice, when to write one, building the timeline, contributing factors, action items, a template and how to run the review.

What blameless means

John Allspaw set out the idea for software teams in a 2012 Etsy post, Blameless PostMortems and a Just Culture. A just culture balances safety with accountability. Engineers who contributed to an incident can describe their actions, observations, expectations, and assumptions without fear of punishment.

Allspaw's reasoning is practical. An engineer who expects reprimand will omit details that explain the failure. A failure nobody understands tends to repeat.

The Google SRE book chapter on postmortem culture defines a blameless postmortem as one that examines contributing causes without indicting any individual or team. It assumes everyone acted with good intentions given the information available. The book also says that you cannot fix people, but you can fix systems and processes.

Blameless does not mean no accountability. Allspaw notes that involved engineers remain responsible for helping the organization improve. They are the best people to explain how to avoid repeating the error.

In writing, blameless means describing what the system allowed, not what a person failed to do. Illustrative rewrites:

Blameful	Blameless
"Sam ran the wrong migration on production."	"The migration ran against production because the deploy tool defaults to the production environment."
"The on-call engineer ignored the alert."	"The alert fired in a channel that also receives about 200 low-priority messages a day, and was not noticed for 40 minutes."
"Human error."	"The runbook step and the actual command differed; the runbook had not been updated since the cluster was renamed."

Name roles, not people, in the document. Hindsight bias is the main trap. Allspaw lists it, along with the fundamental attribution error, as something to work actively against.

When to write one

Define the triggers before an incident occurs. Do not make this decision case by case. The Google SRE book specifies these conditions:

• User-visible downtime or degradation that exceeds a defined threshold.
• Any data loss.
• On-call intervention, such as rolling back a release or rerouting traffic.
• Resolution time that exceeds a defined threshold.
• A monitoring failure, which usually means a person found the problem before an alert did.

Google also allows any stakeholder to request a postmortem for an event. Other published policies set the bar by severity: PagerDuty writes one for every Sev-1 and Sev-2 incident, and Atlassian for severity 1 and 2, with lower severities optional. Tie your triggers to your severity levels.

Who owns it, and how fast

• One owner. PagerDuty has the incident commander pick one responder as owner at the end of the incident, typically someone who led the investigation or was primary on call for the most affected service. One named owner avoids everyone assuming someone else will write it. Writing is still collaborative.
• A deadline. PagerDuty's own policy is to complete the postmortem within 3 calendar days for Sev-1 and 5 business days for Sev-2. Memories fade quickly, so set a deadline measured in days, not weeks.
• Approval. At Atlassian the owning team's postmortem owner drives it to approval by named approvers, who are expected to prioritise the follow-up work.

Build the timeline

PagerDuty's writing guide gives three rules for the timeline:

• Start before the incident began and work forward, not backwards from the fix. This limits hindsight bias.
• Record facts: changes in status and impact, and the key decisions and actions of responders. Pull them from the incident channel, where the scribe logged them.
• Attach a source to each entry: a graph, a log search or a link.

Use one time zone for every entry and say which. UTC is the usual choice. A format that works:

2026-03-04 14:02 UTC  Deploy 4812 of checkout-api starts (deploy log)
2026-03-04 14:09 UTC  Checkout error rate rises from 0.2% to 9% (dashboard link)
2026-03-04 14:13 UTC  HighErrorRate alert notifies primary on-call (alert link)
2026-03-04 14:21 UTC  Incident declared, SEV-2; IC and scribe named (channel link)
2026-03-04 14:35 UTC  IC decides to roll back deploy 4812 (channel link)
2026-03-04 14:41 UTC  Error rate back to 0.3%; status page set to Monitoring

The entries above are an illustration of the format, not a real incident.

Contributing factors, not a single root cause

Published practice differs here:

• Atlassian's handbook uses the Five Whys to follow the causal chain to a root cause, and tracks root-cause fixes as "priority actions".
• PagerDuty's guide says there is no single root cause of major failure in complex systems, and that an individual's action should never be considered a root cause.
• Allspaw's later essay The Infinite Hows (2014) argues that chains of "why" push towards a single linear story, often ending at human error, and that a root cause is chosen by whoever decides where to stop asking. He suggests "how" questions instead: what cues people saw, what they expected, what options they thought they had.

A practical middle path is to keep the trigger separate from the conditions. Google's example postmortem has separate Trigger and Root Causes sections. List every contributing factor that made the incident possible, bigger or longer, including detection and response, and give each one an action item or a recorded decision not to act.

Action items that get done

• Each item is a ticket in the backlog of the team that owns the work (PagerDuty and Atlassian both do this), linked from the postmortem.
• Each item has one owner and a due date. Google's example uses the columns Action Item, Type, Owner and Bug.
• Write items to be actionable, specific and bounded (PagerDuty): start with a verb, keep the scope narrow, and make it clear when it is done. "Investigate monitoring" fails all three; "Add an alert when checkout error rate exceeds 2% for 5 minutes" passes.
• Give priority items a deadline policy. Atlassian's priority actions have an agreed SLO of 4 or 8 weeks depending on the service, with reminders and reports.
• Record what you decided not to do, and why, so the trade-off is visible later.
• Review open items regularly. At Atlassian, engineering managers review a report of incidents whose root-cause fixes are still open.

A postmortem template

Copy this structure into your wiki or incident tool. It follows the sections of Google's example postmortem with PagerDuty's impact fields:

# Postmortem: <short title> (<incident ID>)

Date of incident: <YYYY-MM-DD>    Severity: <SEV level>
Owner: <name>    Status: <draft / in review / final>
Incident commander: <name>    Review meeting: <date>

**Summary**
<Two or three sentences: what broke, who was affected, how long, how it was fixed.>

**Impact**
- Duration of user impact: <start - end, UTC> (may start before detection)
- Users or customers affected: <number or estimate, and how measured>
- Support contacts: <number of tickets or chats>
- Functionality affected: <what users could not do>

**Detection**
<How the incident was found: which alert, or which person. Time from start to detection.>

**Trigger**
<The change or event that started it.>

**Contributing factors**
1. <Condition that made it possible, worse or longer>
2. <...>

**Resolution**
<What stopped the impact, and when.>

**What went well**
- <...>

**What went wrong**
- <...>

**Where we got lucky**
- <...>

**Action items**
| Action | Type (prevent / mitigate / detect / process) | Owner | Due | Ticket |
|---|---|---|---|---|
| <verb + specific change> | <type> | <name> | <date> | <link> |

**Timeline (UTC)**
<YYYY-MM-DD HH:MM>  <event> (<source link>)

**Supporting information**
<Links to dashboards, logs, chat channel, related postmortems.>

Running the review meeting

From PagerDuty's postmortem meeting guide and Atlassian's handbook:

• Send the document 24 hours ahead. Expect attendees to have read it. Do not read it aloud in the meeting.
• Invite the incident commander, service owners, and key engineers involved. Include engineering and product managers for the affected systems. Add the customer liaison for the most severe incidents.
• Use a facilitator who is not the owner, the incident commander, or anyone who responded. The facilitator keeps the review blameless and on track, and says as little as possible.
• Ask "what" and "how", not "who" and "why". Avoid yes or no questions.
• Get commitment. The goal is agreement on action items, with leadership confirming which ones to prioritize and which to defer.

A suggested agenda:

1. Reminder: this review is blameless, and why.            (facilitator)
2. Summary, impact and timeline; corrections from the room. (owner)
3. Contributing factors: "How did we get here?"            (facilitator)
4. What went well, what could have gone better, where we got lucky.
5. Action items: will they work, what is missing, who commits. (owner + leads)
6. Customer impact and the external summary, if one is due.  (customer liaison)

Share it

The Google SRE book says an unreviewed postmortem might as well never have existed. Publish reviewed documents so other teams can read them. Google shares an interesting postmortem with the whole organization in a monthly newsletter. Atlassian turns approved postmortems into Confluence blog posts. If customers were affected, publish a shorter external summary. See what to write on a status page.

Tools

Incident management tools can build the timeline from the incident channel and track action items. See the incident management directory, tools filtered by postmortems, and more templates in the reading list.