On this page (10 sections)
An incident review, also called a postmortem or post-incident review, is how a team learns from an outage without looking for someone to blame. The board follows the incident in order: What happened, How we found out, How we responded, What contributed and Follow-ups. Facts come first, causes second, and the follow-ups are what's left when the meeting ends.
The five columns
| Column | What goes here | Example note |
|---|---|---|
| 📅 What happened, in order | The timeline: timestamped facts, no opinions | "14:09 UTC: checkout error rate reaches 22%." |
| 🔔 How we found out | Detection: the first signal, how long it took, what should have fired | "A customer emailed at 14:15. Our alert fired at 14:21." |
| 🧯 How we responded | What helped, what slowed us, where we got lucky | "Rollback took 14 minutes because the runbook link was dead." |
| 🔍 What contributed | Conditions that made it possible or worse, usually several | "The connection pool change shipped in the same deploy as the feature." |
| 🛡️ Follow-ups | Changes that make the next incident less likely or smaller | "Alert when checkout errors pass 5% for 3 minutes." |
How the board maps to a postmortem document. The example postmortem in Google's SRE book has a summary, impact, trigger, root causes, resolution, detection, lessons learned (including "where we got lucky"), action items and a timeline. The board keeps what the meeting needs: timeline and detection get columns, Response holds the resolution and lessons, What contributed holds trigger and root causes, and Follow-ups are the action items. Put the impact in the retro's name ("Checkout errors, 38 min, Oct 14"). Start each timeline note with a UTC time, since the board sorts by votes or newest.
Where it comes from. No single person invented the incident review, and Google's SRE book traces blameless culture to healthcare and aviation. Two sources popularized it in software. John Allspaw's "Blameless PostMortems and a Just Culture" (Etsy, 2012) asked engineers to give a full account of what they did, saw, expected and assumed, without fear of punishment. Chapter 15 of Google's Site Reliability Engineering (2016), "Postmortem Culture: Learning from Failure", says a blameless postmortem assumes good intentions and focuses on contributing causes, because you can fix systems and processes, not people.
In Retro Rabbit
The Incident Review template in Retro Rabbit
Pick Incident Review from the format library when you create a Team Room (or later in its Settings) and the board starts with its five columns. Your team adds notes during the sprint, with or without their name shown, then votes on what to talk about.
Incident Review · Sprint #14
Example notes
What happened, in order
- 14:02 UTC: deploy of payments-api v2.31 starts2 votes
- 14:09 UTC: checkout error rate reaches 22%4 votes
How we found out
- First signal was a customer email at 14:15, not an alert5 votes
- Error alert fired at 14:21; threshold is 25% for 10 minutes3 votes
How we responded
- Rollback took 14 minutes because the runbook link was dead3 votes
- 30 people joined the incident channel and nobody was clearly leading2 votes
What contributed
- Connection pool change shipped in the same deploy as the feature1 vote
- Canary only covers 2% of traffic in one region1 vote
Follow-ups
- Alert when checkout errors pass 5% for 3 minutes4 votes
- Move the rollback runbook into the repo and link it from the alert5 votes
- What happened, in order
- How we found out
- How we responded
- What contributed
- Follow-ups
14-day free trial · No credit card
When to use it (and when not to)
Use it after:
- user-visible downtime or slowness beyond the threshold your team agreed
- any data loss
- an on-call intervention, such as a rollback
- a slow resolution, or a person spotting it before monitoring did
- a near miss, like a bad deploy caught by the canary
Most follow the SRE book's suggested triggers. Agree on yours in advance.
Pick something else when:
- it's one recurring bug without a messy timeline. 5 Whys is faster.
- it's a slow trend with many suspects, like creeping latency. Use a fishbone.
- you're reviewing a whole release or project. Try a release retrospective or a project post-mortem.
How to run it live (60 minutes)
| Time | Step |
|---|---|
| 0–5 min | Review open follow-ups and restate the impact |
| 5–20 min | Walk the timeline in order and fill the gaps |
| 20–28 min | Detection: how we found out, and how to find out sooner |
| 28–36 min | Response: what helped, what slowed us, where we got lucky |
| 36–48 min | Contributing factors, then dot vote |
| 48–60 min | Follow-ups with owners, top votes first |
- Check old follow-ups first. Open Previous Retro and Old / Unresolved Items in the Action Items panel. If an open follow-up from an earlier incident would have prevented this one, say so. That's a finding, not an accusation.
- Set the frame. Say it out loud: we're here to understand how this happened, and everyone acted on what they knew at the time.
- Walk the timeline. Read the notes in time order and let responders fill gaps. No "should have" yet, only what happened and what people saw.
- Contributing factors. Write silently for five minutes, then dot vote, three votes each. Expect several factors, not one root cause.
- Follow-ups. Turn the top factors into follow-ups with owners. Keep only the ones the team will finish.
How to run it async over a sprint
Here the "sprint" is the few days after the incident, while memory is fresh.
- Within a day: the incident lead starts the review and posts the impact as the first timeline note. Starting a retro closes the board in progress, so if your sprint board is still open, either run reviews in a Team Room kept for incidents (each Team Room is billed as one team) or make it your next retro: pick Incident Review with Try a different format in Start New Retro.
- Days 1–2: responders add timestamped notes from the incident channel, alerts and deploy logs. Turn off Show Name to post about your own actions without your name shown.
- Day 3: the facilitator looks for gaps ("What happened between 14:21 and 14:29?") and asks whoever would know.
- Day 4: everyone adds detection, response and contributing-factor notes, then votes.
- Review day: a 30-minute call on contributing factors and follow-ups. Then share the write-up: the SRE book warns that a postmortem nobody reviews might as well not exist.
More in how to run an async retrospective.
9 example prompts
What happened, in order
- What was the first thing that changed, and when?
- What did each responder see, and what did they expect to see?
How we found out 3. Did monitoring find this, or a person? 4. Which alert should have fired first, and why didn't it?
How we responded 5. What information was hard to find during the incident? 6. Was it clear who was leading, and who was updating customers? 7. Where did we get lucky?
What contributed 8. What was already true before the trigger that made it possible?
Follow-ups 9. Which open follow-up from a past incident is relevant here?
Facilitator tip and a common pitfall
Tip: pick a facilitator who wasn't on call. The incident lead knows the most, so they should answer questions, not run the meeting. A neutral facilitator also notices when the room drifts toward blame.
Pitfall: "human error" as a contributing factor. "The engineer ran the wrong command" ends the conversation where it should start. Ask, as Allspaw does, what the engineer saw, expected and assumed. The useful factor is nearby: the two commands look alike, the prompt didn't show the environment, the runbook was out of date.
How AI helps with this format
On Pro AI (and during the free trial), CarrotIQ drafts the paperwork:
- Summaries. The Sprint Summary covers each column and the whole review: a first draft of the written postmortem.
- Group names. Drag "alert threshold too high" onto "alert waits 10 minutes" and CarrotIQ names the group, for example "Late Alerting".
- Suggested action items. CarrotIQ Suggest drafts a follow-up from the most-voted notes and skips actions that already exist, which helps when some were created mid-incident.
Example action items
| Note | Action item |
|---|---|
| Found out: "A customer told us before the alert did" | "Mei lowers the checkout alert from 25% over 10 minutes to 5% over 3. Check: replaying Oct 14's metrics, it fires by 14:12." |
| Responded: "Runbook link dead, rollback took 14 min" | "Tom moves the rollback runbook into the repo and links it from the alert. Test: a timed staging drill, target under five minutes." |
| Contributed: "Pool change shipped with the feature" | "Ines adds a CI check that flags infrastructure config bundled with feature code. The team reviews the first two flagged PRs." |
| Responded: "30 people in the channel, no clear lead" | "Grace adds an incident lead line to the channel template, for the on-call to claim first. Checked at the next review." |
See retrospective action items that actually get done.
Use this template in Retro Rabbit
- Start a 14-day free trial. No card is needed.
- For one retro, click Try a different format in Start New Retro and pick Incident Review: it applies to that retro only, and your Team Room keeps its usual columns. To make it the room's format, choose it under "Browse all formats" when you create your Team Room, or later in the Team Room's Settings.
- Name the retro after the incident in the same dialog, with its impact. Open follow-ups from past incidents stay under Old / Unresolved Items for the next review.
See pricing for plans.
Related formats
- 5 Whys: dig into one contributing factor
- Fishbone: for slow-building problems with many suspects
- Timeline retrospective: rebuild a whole sprint in order
- Pre-mortem: imagine the next incident before it happens
- More formats in Incidents and postmortems
- All retrospective templates
Frequently asked questions
What is an incident review?
A meeting and write-up after an outage or near miss, where the team rebuilds what happened, how it was found and handled, and what made it possible. It's also called a postmortem or post-incident review. The output is a short list of follow-ups that make the next incident less likely or smaller.
What does blameless mean in an incident review?
It means assuming everyone acted with good intentions on what they knew at the time, and looking for the conditions that made the incident possible instead of a person to punish. Google's SRE book and John Allspaw at Etsy popularized this approach in software.
When should a team hold an incident review?
Agree on triggers in advance. Google's SRE book suggests user-visible downtime beyond a threshold, any data loss, an on-call intervention such as a rollback, a long time to resolve, or a monitoring failure. Hold it within a few days, while people remember.
Who should attend an incident review?
The responders, the owners of the affected systems, and anyone who dealt with customers during the incident. The facilitator works best if they weren't on call, so the people who were can focus on answering questions.
Should an incident review find one root cause?
Usually not: most incidents have several contributing factors, a trigger plus conditions that made it possible or worse. Listing them separately gives you more places to act. Use 5 Whys if one factor needs a deeper look.
Does the board replace a written postmortem?
No. The board is where the team builds the facts and agrees on follow-ups. Still write a postmortem document for people outside the team; the CarrotIQ summaries make a useful first draft.
Run this retro in Retro Rabbit
Your team adds notes during the sprint, CarrotIQ groups and summarizes them and suggests action items, and unfinished items carry into the next retro.
14-day free trial · No credit card