Meeting canvases · Deliver and recover
Incident postmortem: a blameless review, built live
An incident postmortem, also written post-mortem or called a post-incident review, is a blameless review held after an outage or failure to agree what happened, who was affected, why it happened and what will change. The team rebuilds the timeline together and looks for the conditions that made the failure possible, not for a person to blame.
Troopa builds the review board during the call on Teams, Zoom or Google Meet. Each time people remember goes on the timeline in order, “at 14:05 the alerts fired”, with the impact, the chain of causes, what went well and the follow-ups in sections of their own; Troopa offers the board as soon as the meeting is called an incident review.
14 days free, no card. Then $15 per seat, per month. Cancel any time. Last checked against the product on 21 October 2026.
Why incident reviews go wrong
- The meeting is spent reading the write-up aloud instead of finding what let the failure happen.
- People who expect to be blamed say less, so the timeline has holes exactly where it matters.
- “Human error” goes down as the cause, and nobody asks what check would have caught it.
- Follow-ups end with four owners or none, and the same incident comes back months later.
- The review is skipped because “we know what happened and it’s fixed”, so nothing is learned.
- Times are pieced together afterwards from chat logs, and half of them are an hour out.
How to run an incident postmortem with Troopa
Step 1: Open the review
Call the meeting an incident review and Troopa offers the board as it starts. Or say “Hi Troopa, open an incident review for Saturday’s checkout outage”.
Step 2: Walk the timeline together
Say the times as people remember them, and each event goes on the timeline in time order, whoever says it and whenever it comes back to them.
Step 3: Ask why, and why again
Causes go in as a numbered chain, the 5 whys habit, so the room can follow “the processor timed out” back to the load test that left out the sale’s traffic.
Step 4: Agree the follow-ups
Each follow-up goes on the board with the name of whoever takes it. Put them in your own tracker after the call, where the work is done.
Step 5: Share the write-up
Present the board to close the meeting, then download it as Markdown or PDF for the write-up, or as CSV for your tracker.
A worked example: a checkout outage on sale day
An online retailer’s checkout failed for twenty-two minutes during a Saturday sale. On Monday the team reviews it on Zoom; Kemi runs the review with Troopa open.
- Kemi“Hi Troopa, open an incident review for Saturday’s checkout outage.”
- Raj“At 14:05 the payment alerts fired. By 14:12 we could see the card processor timing out.”
- Lou“We switched to the backup route at 14:20, and checkout was back at 14:27.”
- Raj“About nineteen hundred orders failed in those twenty-two minutes.”
- Kemi“Why did the processor time out? The new fraud rule called it twice for every order. Why didn’t we catch that? The load test left out the sale’s traffic.”
- Lou“What went well: the backup route worked first time.”
- Kemi“Follow-ups: Raj adds the sale traffic to the load test, and Lou adds an alert on the processor’s response time.”
Incident reviews outside the engineering team
Fintech and payments
A failed payment batch or a card authorisation outage, reviewed with operations, engineering and compliance together. In the EU, the Digital Operational Resilience Act expects financial firms to review a major ICT incident afterwards.
E-commerce
A checkout outage on a sale day, a stock sync that oversold, or a promo code that broke the margin: the timeline, what it cost in orders, and the changes before the next sale.
Public sector
A service team after an outage, following the Government Digital Service’s advice to hold a blameless incident review and record what it learned, and the National Cyber Security Centre’s for a cyber incident.
Any organisation holding personal data
A data breach review: what was exposed, when it was found, and what changes. In the UK the ICO expects a record of every personal data breach, reported or not, and the review is where those facts come together.
Manufacturing
A line stoppage or a quality escape, reviewed with the operators who were there. The five whys came from the factory floor, and the chain of causes on the board is the same habit.
Agencies
A campaign email sent to the wrong list, or a client’s site down on launch day. The review often includes the client, and the board feeds both the fix and the message to the client.
A blameless postmortem template
Draft it within a day or two, while people remember, and send the draft round before the incident review meeting, so the meeting can discuss it rather than read it. Name one owner for the review itself.
Incident: [name and ID] Severity: [level] Date: [date, with the time zone] Owner of this review: [name] Review meeting: [date] Summary: [two or three sentences: what happened, for how long, to whom] Impact: [customers or users affected, how long, orders, money, data] Timeline (in order, with the time zone) [HH:MM] [first sign] [HH:MM] [noticed by / alert] [HH:MM] [what was tried, and what worked] [HH:MM] [all clear] Causes (ask why, then why again) 1. [what failed] 2. [what made that possible] 3. [what made that possible] Went well: [...] Went badly: [...] Where we got lucky: [...] Follow-ups - [action, specific and bounded] · [prevent / detect / mitigate] · [owner] · [due date]
Questions that keep a review blameless and useful
- What were you looking at when it started, and what did we not notice?
- What was different from what we expected, and have we seen this kind of problem before?
- Did we have the information and the tools we needed, and were the right people involved?
- Ask “how” and “what”, never “who”: a review that hunts for a culprit stops hearing the truth.
- Where the cause looks like human error, ask what check, alert or step would have caught it.
- Share the write-up beyond the team, and look back over past reviews every month or so.
Questions about incident postmortems
What is a blameless postmortem?
A blameless postmortem looks for the conditions that let an incident happen, such as a missing check or an unclear process, rather than the person who made the last mistake. People speak more openly when they are not afraid of blame, which is what makes the timeline and the causes accurate.Google, Site Reliability Engineering, chapter 15: Postmortem culture →
When should you hold an incident postmortem?
After any incident at or past an agreed severity, such as one customers noticed, data lost, or a long outage, and whenever someone asks for one. Many teams draft the write-up within a day or two and meet within the week, while memories are fresh.The GDS Way, How to manage technical incidents →
Does the law require an incident review?
Sometimes. In the EU, the Digital Operational Resilience Act requires financial firms to review a major ICT incident that disrupted their core activities. In the UK, the ICO expects every organisation to keep a record of each personal data breach, whether or not it had to be reported. This is general information, not legal advice.Regulation (EU) 2022/2554, the Digital Operational Resilience Act, Article 13 →ICO, Personal data breaches: a guide →
Postmortem or post-mortem?
Both are right. American engineering teams usually write postmortem as one word, British English hyphenates it as post-mortem, and UK government and many large organisations call it a post-incident review. Saying “incident” makes it clear the meeting is not about a project or anything medical.
What should an incident postmortem include?
A short summary, the impact, a timeline with times and their time zone, the causes, what went well and badly, and follow-ups with one owner and a date each. Many templates add how the incident was detected and what message went to customers.
Is the 5 whys still worth using?
As a habit, yes: asking why repeatedly gets past the first symptom to what made it possible. The number five is not the point, and complex incidents rarely have one root cause, so many teams list several contributing causes instead of forcing one chain.Lean Enterprise Institute, Lean Lexicon: 5 Whys →
What is the difference between a postmortem and a retrospective?
A postmortem is held after one incident, to reconstruct it and learn from it. A retrospective is held regularly, at the end of every sprint or phase, whether anything went wrong or not, to improve how the team works.
Sources
- Google, Site Reliability Engineering, chapter 15: Postmortem culture
- The GDS Way, How to manage technical incidents
- National Cyber Security Centre, Incident management: your cyber incident response processes
- Lean Enterprise Institute, Lean Lexicon: 5 Whys
- Regulation (EU) 2022/2554, the Digital Operational Resilience Act, Article 13
- ICO, Personal data breaches: a guide
Read on 15 October 2026, by the people who make Troopa.
Try it in your next meeting
Install Troopa on your Mac, Windows PC or Ubuntu computer, join your call on Teams, Zoom or Google Meet as you always do, and ask: “Hi Troopa, open an incident review for Saturday’s checkout outage.”
14 days free, no card. Then $15 per seat, per month. Cancel any time.