Post-Incident Review Template: Blameless PIR & Examples

What's in this guide

• The six rules that make a review blameless in practice, not just on the poster
• The template, section by section, with what to write and what to leave out
• A fully worked example: a 59-minute checkout outage, written up end to end
• The template itself, to copy or download as Markdown or Word
• Where tooling helps, and the honest case for a plain Google Doc
• The trade-offs, including when you should not run a full review at all

Post-incident review vs post-mortem, briefly

Same document, different name. "Post-mortem" is the older term and the one most engineers search for; "post-incident review" is gaining ground because nobody died and some teams would like the vocabulary to reflect that. If you want the short definition, the post-mortem template glossary entry has it.

What the definition cannot tell you is the uncomfortable part. Most PIRs fail after the document is finished. The timeline is accurate, the root cause is sensible, the action items are reasonable, and ninety days later half of them are still open and the same incident happens again with a different ticket number. So this guide spends as much time on the action items and their owners as on the analysis, because that is where the value either lands or leaks out.

It also helps to know where a PIR sits. It is the qualitative half of incident reporting: your reports tell you that MTTR crept up this quarter, and the reviews tell you why. A team with reports and no reviews has numbers it cannot explain. A team with reviews and no reports has stories it cannot weigh.

Blameless PIR principles: six rules that survive contact with a real incident

Everyone agrees reviews should be blameless. Then the review starts, someone says "so why did you push that on a Friday?", and the room learns what the policy is really worth. The cultural side is covered in the blameless culture glossary entry. Here are the mechanics that make it hold inside one document and one meeting.

1. Ask how it made sense at the time

Every decision in your timeline made sense to the person who made it, given what they knew then. Your job is to reconstruct what they knew. "The engineer rolled back the wrong service" is a verdict. "The dashboard showed errors on both services, and the payments one was louder" is a finding, and it points at the dashboard.

2. Human error is where the investigation starts, not where it ends

If your root cause section says "human error", you have stopped one question too early. People will always make some errors; no review process changes that. The useful question is why this particular error reached production, why nothing caught it, and why it took as long as it did to notice.

3. Ban counterfactual language in the document

"Should have", "failed to", "neglected to" and "didn't bother" describe a world that did not happen, and they all carry blame in the grammar. Replace them with what did happen. "The alert was not acknowledged for 14 minutes" is a fact you can fix. "On-call failed to respond" is an accusation you can only defend against.

4. Use roles in the narrative, names in the owner column

Write "the on-call engineer" and "the incident commander" in the timeline. Put real names next to action items. The narrative is about the system; the action items are about who will change it. Mixing them up is how teams end up with anonymous action items and a named culprit, which is precisely backwards.

5. The facilitator is not the person closest to the incident

The engineer who was paged is your most important witness and your worst facilitator. Pick someone from an adjacent team who can ask naive questions without it sounding like cross-examination. On small teams, rotate the job so nobody facilitates their own incident.

6. Build a firewall between reviews and performance management

Blameless reviews only work if people believe that what they say in one will never show up in their annual review. So make it a written rule, not a vibe: PIR documents are never cited in performance conversations. The first time a manager breaks that rule, every future timeline gets quietly less accurate, and you will not notice, because the gaps are invisible by design.

Blameless is not consequence-free. The consequences just land on the system rather than the person. A blameless review that produces no action items is not blameless, it is decorative.

When to run a PIR, and when not to

Not every incident deserves a full review. Running one for every blip turns the process into paperwork, and paperwork is where good intentions go to be ignored.

A reasonable default, tied to your incident severity levels:

The last row matters most. A near miss is an incident where you got lucky, and the review costs you nothing in customer trust. Teams that only review incidents that hurt customers are learning from the most expensive examples available.

Also run one, regardless of severity, if the same thing has happened twice in a quarter. Once is an incident. Twice is a pattern your last review missed.

The template, section by section

The template has five core sections plus a header. You can add more; resist the urge. Every extra section is another place for the document to stall.

Header and summary

Incident ID, severity, date, status, the facilitator, and the date of the review meeting. Then a three-sentence summary: what broke, who noticed, what you are changing. Write the summary last. If you write it first, you will anchor on your first theory and then spend the rest of the document defending it.

1. Timeline

The timeline is the spine of the review, and it has one rule: source it from records, not memory. Alerts, acknowledgments, deploy logs, chat messages, status page updates. Memory compresses a 50-minute incident into "we found it pretty quickly", and that compression is exactly where the learning was.

Things to include that people usually leave out:

• The trigger, even if it happened hours before anyone noticed. The gap between a change and its first alert is often the most useful number in the whole review.
• Dead ends. The 20 minutes spent investigating the database that turned out to be healthy is not embarrassing, it is data about your observability.
• Communication events. When the status page was updated, when support heard, when the first customer email went out.

Close the timeline with four durations: time to detect, time to acknowledge, time to mitigate, and total customer impact. If your incident tool already tracks the acknowledge and resolve times, copy them rather than reconstructing them. Definitions for MTTD, MTTA and MTTR are in the glossary if your team uses the terms loosely, which most do.

2. Impact

Numbers first, adjectives never. "Significant disruption" tells a reader nothing. "18% of checkout attempts failed for 59 minutes, about 1,400 in total" tells them everything, including whether this was worth the meeting.

Cover who was affected, what they experienced, how many, for how long, and what it cost: support tickets, SLA exposure, and how much of your error budget it consumed. If you are estimating, say how. An estimate with a method beats a precise number nobody can reproduce.

3. Root cause and contributing factors

The section heading says "root cause" because that is what everyone searches for. The content should say "contributing factors", because incidents in real systems rarely have one. They have a trigger and a set of conditions that let the trigger become an outage.

Structure it as four questions:

1. Why was the trigger possible? The change, the config, the dependency.
2. Why was it not caught before production? Review, tests, staging.
3. Why did detection take as long as it did? Alert thresholds, missing signals.
4. Why did mitigation take as long as it did? Missing context, slow rollback, wrong first guess.

Each of those gets its own answer, and each answer gets an action item or an explicit "we accept this risk". That mapping is the difference between a review and a story.

A word on the 5 Whys, since every template mentions it. It is a fine way to get a stuck conversation moving, and a poor way to finish one, because it walks a single causal chain and incidents are rarely a chain. Use it to find the first contributing factor, then ask what else had to be true. The root cause analysis entry covers the wider toolkit.

Finish the section with what went well. This is not a morale exercise. Things that worked are things you can accidentally break in the next reorganisation, so write them down while you still know why they worked.

4. Action items

This is the section that decides whether the review was worth doing. Four rules:

• Every action is tagged Prevent, Detect or Mitigate. A review with five Prevent actions and nothing else has assumed you will never be surprised again, which is optimistic.
• Every action is small enough to finish in 30 days. "Improve observability" is not an action item, it is a mood. "Alert when connection pool wait time exceeds 200 ms for 3 minutes" is an action item.
• Every action lives in the team's real backlog. Action items that only exist inside the PIR document are wishes. Link the ticket.
• Write down what you considered and rejected. "Retrain the engineer" belongs here, with the reason you rejected it. The list stops the same bad idea from being proposed at the next review.

5. Owners and follow-up

One person per action, not a team. "Platform team" owns nothing; Priya owns something. Then name one person who owns the document until every action closes, and put a 30-day check in the calendar the day you finish the review, not when you remember.

The 30-day check has three possible outcomes per action: closed, slipped with a new date, or deliberately dropped with a reason. Dropping an action is allowed. Letting it rot is not. An honest "we decided this isn't worth it" is useful information; a ticket silently aging in a backlog is a lie the whole team has agreed not to mention.

Worked example: a 59-minute checkout outage

Here is the template filled in, end to end, for a fictional but thoroughly ordinary incident. Nothing exotic broke. That is the point: most outages are boring causes meeting unlucky timing.

Post-Incident Review: Checkout requests failing after config deploy

Incident ID: INC-2291 · Severity: SEV-2 · Status: Final

Facilitator: Engineering manager, Search team (not involved in response)

Review meeting: 3 business days after resolution

Summary. A routine config change reduced the checkout service's database connection pool from 100 to 10, and under midday load checkout requests queued and timed out for 59 minutes, failing about 1,400 purchases. It was detected 12 minutes after impact began and mitigated by rollback once responders connected the errors to the deploy. We are making the pool size explicit per service, alerting on pool saturation, and posting deploys into incident channels automatically.

1. Timeline (UTC)

2. Impact

• Who: All customers attempting checkout. Browsing, search and accounts unaffected.
• What they saw: Checkout spinner, then an error page after 30 seconds.
• How much: 18% of checkout attempts failed on average, peaking at 31% at 12:20. About 1,400 failed attempts. Order logs show roughly 60% of affected customers retried successfully within the hour; the remainder are counted as at-risk revenue.
• Business effect: 23 support tickets. Around a quarter of the month's 99.9% checkout availability budget consumed (18% failure over 59 minutes ≈ 10.6 minutes of full-outage equivalent, against a 43-minute monthly budget).
• Communication: Status page updated at 12:06, 12:33 and 12:52. No customer email; judged unnecessary given resolution time.

3. Root cause and contributing factors

Trigger: The shared default pool size changed from 100 to 10, and checkout relied on the default rather than setting its own value.

Contributing factors

1. Why was it possible? Service configs inherit shared defaults silently. Nothing tells a service owner that a value they depend on has changed.
2. Why wasn't it caught? The PR was 14 files, framed as a refactor, and reviewed as one. Nothing marked the pool change as a behaviour change, and staging traffic is too light to exhaust even 10 connections.
3. Why did detection take 12 minutes? The error-rate alert needs 5% for 10 minutes. The error rate crept up with traffic rather than jumping, so it spent 12 minutes between "clearly broken" and "alert-worthy".
4. Why did mitigation take 47 minutes? The deploy was not visible in the incident channel, and slow checkout looked like a database problem. Responders spent 19 minutes confirming the database was fine.

How it made sense at the time: The PR author changed a value labelled as a default in a file named "defaults", in a PR whose stated purpose was cleanup. The reviewer read the description, confirmed the diff matched it, and approved. The first responders saw slow checkout requests and went to the database because that is the most common cause of slow checkout requests on this system. Every decision was reasonable given the information available. The information was the problem.

What went well: Rollback took 8 minutes and worked first time. Support escalated within minutes of the first ticket. The status page went up within 2 minutes of declaration.

4. Action items

Considered and rejected

• Require two reviewers on config PRs. Rejected: the reviewer did their job; a second reviewer would have read the same misleading framing. Action 2 routes the review to the people with the context instead.
• Load-test staging on every deploy. Rejected for now: high cost, and actions 1 and 3 cover this failure more cheaply. Revisit if a second capacity-related incident occurs this quarter.

5. Owners and follow-up

30-day check (added later): Actions 1, 3 and 4 closed. Action 2 closed. Action 5 slipped by two weeks, new date agreed, owner unchanged.

What makes this example work

Three things worth stealing. The dead end is in the timeline, and it produced the most valuable action item on the list (number 5). The "how it made sense" paragraph turns a review that could have been about a careless PR into one about silent inheritance, which is the thing that will bite you again. And the rejected actions are written down, so when someone proposes a second reviewer after the next config incident, the answer is already on file.

Download the post-incident review template

The blank template, with the prompts from this guide built in, is free to copy and adapt. No email address required.

• Download as Markdown (.md) for Confluence, Notion, GitHub, or any wiki that speaks Markdown
• Download as Word (.docx) for Google Docs and Word

Or copy the skeleton straight from here:

POST-INCIDENT REVIEW: [Incident title]

Incident ID | Severity | Date | Status | Facilitator | Review meeting

0. SUMMARY (write last, three sentences)

1. TIMELINE (UTC, from records, roles not names, include dead ends)

   Time | Event | Source

   Key durations: detect | acknowledge | mitigate | total impact

2. IMPACT (numbers first: who, what, how many, how long, cost)

3. ROOT CAUSE AND CONTRIBUTING FACTORS

   Trigger:

   Why was it possible? / Why not caught? / Why slow to detect? / Why slow to mitigate?

   How it made sense at the time:

   What went well:

4. ACTION ITEMS

   # | Action | Prevent/Detect/Mitigate | Owner (one person) | Due | Ticket

   Considered and rejected:

5. OWNERS AND FOLLOW-UP

   Document owner | 30-day check (who, when) | Approved by

How to adapt it. Delete sections before you add them. If your team runs a sailboat retrospective or another format for the meeting itself, keep it; this template is the written record, not the meeting agenda. And keep one copy of the template in one place. Three slightly different templates across three teams means nobody can compare reviews, which is half the reason to have a template at all.

Where tooling helps (and where a Google Doc is fine)

Here is the honest version: you do not need a tool to run good post-incident reviews. A shared doc, a calendar reminder and a team that keeps its word will beat an expensive platform used by a team that does not. What tooling changes is how much of the document you have to reconstruct by hand.

Worth automating

• The timeline. Alert fired, who was paged, who acknowledged, when it escalated, when it resolved. If a human is typing these timestamps from memory, the timeline is already wrong.
• The durations. Time to acknowledge and time to resolve should come out of your incident tool, per incident and as a trend, so the review can say whether this one was typical.
• The document skeleton. Creating the review doc, pre-filled with the incident's details, in the place your team already writes.
• Deploy and change events alongside alerts. The worked example's most valuable action item was exactly this.

Not worth automating

• The contributing factors. Anything that writes this section for you is guessing, and a confident guess in a review document is worse than a blank.
• The "how it made sense" paragraph. Only the people involved can supply it.
• The follow-through. No tool makes a team finish its action items. A calendar invite and an owner do.

For what it is worth, All Quiet covers the first three: it keeps a timestamped history of every alert, acknowledgment, escalation and resolution, reports MTTA and MTTR per incident and over time, and can create a post-mortem page pre-filled with incident details in Confluence, Google Docs or Notion. The Standard plan is $4.99 per user per month on the US price list (EU-hosted accounts are billed 6,99 €, because the price follows the hosting region), with no sales call required to see it. It will not write your contributing factors and it will not close your action items. If your team's problem is follow-through rather than data collection, fix that first with the tools you already have; the template above works in any of them.

The trade-offs nobody mentions

Reviews cost more than they appear to. In our experience a full PIR takes somewhere around four to eight person-hours once you count the draft, the meeting and the follow-up. For a SEV-2 that is cheap. For every SEV-4 it is a tax that teaches people to under-classify incidents to avoid the paperwork, which corrupts your severity data. Keep the threshold honest.

Blameless reviews can drift into no-conclusion reviews. The failure mode of blamelessness is a document so careful not to point at anyone that it does not point at anything. If your contributing factors are all phrased as "communication could be improved", the review has avoided blame by avoiding content.

A template can become a form to be filled rather than a question to be answered. The fifth review using the same template tends to look suspiciously like the fourth. If the sections are being filled in with the same phrasing every time, the facilitator should start asking the questions out loud rather than letting people type into boxes.

Publishing reviews widely helps, until it doesn't. Sharing reviews across the company spreads the learning. It also raises the stakes of what gets written down. If people start softening timelines because the VP will read them, restrict the full version and publish a summary.

Some incidents do not have a satisfying cause. Occasionally you will not find out why. Write that down plainly, add better detection as the action item, and move on. A plausible invented root cause is worse than an honest "unknown", because it closes the investigation.

Frequently Asked Questions

What is the difference between a post-incident review and a post-mortem?

They are the same document under two names. "Post-mortem" is the older and more widely searched term; "post-incident review" or "PIR" is increasingly preferred because it sounds less final and fits incidents with no customer impact, such as near misses. Both cover the timeline, impact, contributing factors and action items of an incident, ideally in a blameless format.

How soon after an incident should you hold the review?

Draft the document within two business days while memories and logs are fresh, and hold the review meeting within five business days of resolution. Waiting longer loses detail from the timeline and lets the action items compete with a fresh sprint. For lower-severity incidents a written, asynchronous review within a week is usually enough.

Who should attend a post-incident review meeting?

The responders, the owners of the affected services, someone from support or customer success if customers noticed, and a facilitator who was not involved in the response. Keep it under about eight people. Managers can attend if they model the blameless rules; if their presence makes responders more guarded, share the written review with them afterwards instead.

What makes a post-incident review blameless?

A blameless review treats every decision in the timeline as reasonable given what the person knew at the time, and looks for the conditions that made the failure possible rather than the person who triggered it. In practice that means describing people by role in the narrative, avoiding phrases like "should have" and "failed to", and never using review documents in performance conversations.

How do you make sure post-incident action items actually get done?

Give each action one named owner and a due date, put it in the team's normal backlog rather than only in the review document, and schedule a 30-day check on the day the review is finalised. At the check, every action is either closed, rescheduled with a reason, or deliberately dropped with a reason. Keeping each action small enough to finish within 30 days helps more than any tracking tool.

Sources and further reading

The principles in this guide build on a small body of work that most good PIR practice traces back to. All checked 2 October 2026.

• Postmortem Culture: Learning from Failure, Site Reliability Engineering (Google), chapter by John Lunney and Sue Lueder. The standard reference for blameless postmortems and for objective triggers that decide when a review is required.
• Postmortem Culture: Learning from Failure, The Site Reliability Workbook (Google). Includes an annotated good and bad postmortem, action items classified by type, and tracking action items as bugs so they close.
• Blameless PostMortems and a Just Culture, John Allspaw, Etsy Code as Craft, 22 May 2012. The origin of "the action made sense to the person at the time they took it" in software operations.
• How Complex Systems Fail, Richard I. Cook. Points 3 and 7 are the case for "contributing factors" over a single root cause.
• The Field Guide to Understanding 'Human Error', Sidney Dekker (Ashgate, 3rd edition 2014). The longer treatment of local rationality and why counterfactual language ("should have", "failed to") hides what actually happened.