What is the purpose of a post-mortem meeting?

To understand what happened in an incident or project, find the root cause and agree on changes so it doesn't happen again. Google's SRE book names three goals: document the incident, understand all contributing root causes and put effective preventive actions in place.

What is the difference between a post-mortem and a retrospective?

A post-mortem is a one-time review of a single incident or finished project, with a timeline, root cause and written report. A retrospective is a recurring meeting, usually every sprint, about how the team works in general.

How long should a post-mortem meeting be?

About 60 minutes. Draft the timeline beforehand so the hour goes to causes and actions, not to arguing about what happened.

What does blameless mean in a post-mortem?

The review looks for the systems and processes that made the failure possible, not for someone to punish. Google's SRE book says a blameless post-mortem "assumes that everyone involved in an incident had good intentions and did the right thing with the information they had."

Post-Mortem Meeting: Template and Questions

At 4:50 on a Friday, a building-products distributor emailed its fall price list to 3,800 customers. By Monday, contractors were ordering at prices 12% below cost on 140 items, and the sales team spent two days on the phone walking them back. (The distributor is a composite, not a real company.)

The first question in the room was who sent it. That's the question a good post-mortem meeting never asks.

This guide shows you how to run a post mortem meeting that finds the real cause without hunting for a culprit: when to hold one, how it differs from a retrospective, a 60-minute agenda, the five whys, 20 questions sorted by stage, and a one-page template filled in for the price-list mistake.

What is a post-mortem meeting?

A post-mortem meeting is a one-time review held after a project ends or an incident is resolved, where the people involved agree on what happened, why it happened and what will change so it doesn't happen again. The output is a short written post-mortem with a timeline, the root cause and action items with owners.

Google's Site Reliability Engineering book defines that document as "a written record of an incident, its impact, the actions taken to mitigate or resolve it, the root cause(s), and the follow-up actions to prevent the incident from recurring." The idea isn't limited to software. A missed launch, a lost key account or a trade show that produced no leads deserves the same treatment.

When to hold one. The SRE book advises defining "postmortem criteria before an incident occurs so that everyone knows when a postmortem is necessary." Atlassian's incident handbook runs them for its two highest severity levels. Outside engineering, sensible triggers are a customer who lost money, a deadline or budget missed by a set margin, or a finished project with a similar one coming. Hold the meeting within a week, while memories are fresh but tempers have cooled.

Post-mortem vs retrospective

Both look back and change something. The difference is rhythm and depth.

	Post-mortem meeting	Retrospective
When	Once, after an incident or at the end of a project	Every sprint or cycle
Trigger	Something went wrong, or a project finished	The calendar
Focus	One event: its timeline and root cause	How the team worked lately
Output	A written report with actions and an approver	Two or three habits to change

For a regular team check-in, use a retrospective meeting. Use a post-mortem when one event needs a full explanation.

Before the meeting: draft the timeline

A post-mortem goes badly when people spend the hour arguing about what happened. Settle the facts first.

Name one post-mortem owner, usually whoever led the response or ran the project. Before the meeting, they draft a three-sentence summary, the impact (who, how long, what cost), a timestamped timeline from the first warning sign to the fix, and a first guess at causes, marked as a draft.

Write the timeline with roles, not names. Atlassian's handbook tells owners to "refer to individuals by role (eg 'the on-call Widgets engineer') instead of name." In the price-list case, that's "the marketing coordinator" and "the pricing analyst." Share the draft a day ahead.

Rebuilding the timeline from memory? Record the debrief conversations as they happen, and ParrotNotes turns each one into a transcript, summary and action items. Try ParrotNotes free.

A 60-minute post-mortem meeting agenda

Atlassian's suggested agenda opens by reminding the team "that postmortems are blameless, and why," then confirms the timeline and root causes and generates actions. With times added:

Ground rules (5 minutes). The facilitator says out loud that the goal is to fix the system, not to find a person.
Walk the timeline (15 minutes). The owner reads it. Everyone corrects facts and adds what they knew at each moment.
Find the root cause (15 minutes). Run the five whys on the main failure.
Went well, didn't, got lucky (10 minutes). These are Atlassian's three questions. "Where did we get lucky" is the one people skip, and it often points to the next incident.
Agree on actions (10 minutes). Each gets one owner and a due date.
Close (5 minutes). Read actions back, name the approver and set the date the write-up will be shared.

Find the root cause with the five whys

Atlassian's handbook tells owners to use the "Five Whys" technique "to traverse the causal chain until you find a good true root cause." Ask why, take the answer, ask why again. Stop when the answer is a process you can change.

The chain for the price-list email:

Why did customers get wrong prices? The PDF was built from last year's cost tab.
Why that tab? After a supplier merger, the price file had two tabs with almost the same name.
Why didn't anyone catch it? Nobody checked the PDF against the pricing system before the Friday deadline.
Why was there no check? The steps lived in one person's head, and that person was on leave.
Why only one head? The release process was never written down or given a second reviewer.

The root cause isn't "the coordinator picked the wrong tab." It's a process with no written steps and no second check.

Keep the post-mortem blameless

The SRE book says a blameless post-mortem "must focus on identifying the contributing causes of the incident without indicting any individual or team." Its reason is practical: "You can't 'fix' people, but you can fix systems and processes."

John Allspaw made the same case in his 2012 Etsy post, Blameless PostMortems and a Just Culture: people give a full account of what they did and assumed only if they can do it "without fear of punishment or retribution."

Blame creeps in through wording. Swap these phrases:

Instead of	Say
"Who sent this?"	"What did the sender see at the time?"
"Why didn't you check?"	"What would make checking the easy default?"
"That was careless."	"What made the mistake easy to make?"
"This can't happen again."	"What makes this less likely, or faster to catch?"

Post-mortem meeting questions, sorted by stage

Twenty questions to borrow. Pick a few per stage.

Timeline

When was the first sign something was wrong?
Who noticed, and how?
What did each person know at that moment?
Were there earlier warnings we missed?

Impact 5. Who was affected: customers, colleagues, partners? 6. What did it cost in money, time or trust? 7. Is any impact still ongoing?

Causes 8. What made this possible? 9. Why didn't our checks catch it? 10. Has something similar happened before? 11. Which assumption turned out to be wrong? 12. What pressure (deadline, staffing, handoff) shaped the decisions?

Response 13. What went well in how we responded? 14. What slowed us down? 15. Where did we get lucky? 16. How could we have cut the response time in half?

Actions 17. What one change would have prevented this? 18. What would help us catch it sooner? 19. Who owns each action, and by when? 20. Who needs to read this post-mortem?

Question 16 is adapted from Atlassian's handbook, which asks "how would you have cut the time in half?"

Post-mortem meeting template

Copy this one-page post mortem meeting template:

POST-MORTEM
Event:              Date of event:       Meeting date:
Owner:              Approver:            Attendees (roles):

1. SUMMARY (3 sentences)
2. IMPACT: who | how long | cost
3. TIMELINE (roles, not names): time | what happened | what we knew
4. ROOT CAUSE (five whys)
5. WENT WELL / DIDN'T / GOT LUCKY
6. ACTIONS: action | owner | due date | prevent, detect or respond
7. SHARED WITH:                          Date:

Filled in for the price-list email (a composite example):

POST-MORTEM
Event: Fall price list emailed with wrong prices
Date of event: Fri Sep 26     Meeting date: Thu Oct 2
Owner: Sales ops manager      Approver: VP Sales

1. SUMMARY: List sent to 3,800 customers from last year's cost
   tab; 140 items 12% below cost. 31 orders honored, rest
   corrected by phone in two days.
2. IMPACT: 31 orders at a loss; about 60 rep hours on calls
3. TIMELINE
   Fri 16:50  List emailed by the marketing coordinator
   Sat 09:12  First order at the wrong price
   Mon 07:40  A field rep spots the gap on a contractor quote
   Mon 09:30  Corrected list sent; reps start calls
4. ROOT CAUSE: release steps never written down, no second
   reviewer; the one person who knew them was on leave
5. WENT WELL: rep caught it fast; one shared call script
   DIDN'T: no check before send
   LUCKY: errors were on low-volume items
6. ACTIONS
   Written release checklist      | Pricing analyst  | Oct 10 | prevent
   Second reviewer on every list  | Sales ops mgr    | Oct 10 | prevent
   Test send to 5 reps first      | Mktg coordinator | Oct 17 | detect
7. SHARED WITH: whole sales team, Oct 6

Every action changes a process, not a person.

Turn post-mortem actions into done work

The SRE book warns: "An unreviewed postmortem might as well never have existed." Atlassian tracks every action in the owning team's backlog and gives root-cause fixes, its "priority actions," a deadline of four or eight weeks depending on the service.

Copy the idea: one named owner per action, a real due date, an approver who makes sure actions get time, and a date to check they worked. Our guide to action items tracking shows how to chase them across meetings. If the post-mortem changes a policy, record it in a decision log so the next new hire knows why the rule exists.

A month later, the distributor's next price list went out after a test send to five reps. One caught a wrong freight surcharge. No customer ever saw it.

Should you record the post-mortem meeting?

A recording lets the facilitator run the room instead of typing, and settles later arguments about what was agreed. But people will be talking about their own mistakes, so ask first: explain why, who will hear it and how long you'll keep it, and stop if anyone objects. For US legal basics, see our guide to one-party consent states.

If the team agrees, ParrotNotes records on the phone or Mac already in the room, with no meeting bot, and gives you a transcript, a summary and the action items. Paste them into sections 3, 5 and 6 of the template, swapping names for roles. Chat with the transcript to check a detail. On Pro, speaker ID labels who said what, AI search finds answers across every past post-mortem, and 99+ languages with translation cover multilingual teams.

Learn from it once, fix it for good

Agree on triggers in advance. Draft the timeline before the meeting. Keep the hour blameless, find the root cause with the five whys, and leave with a few actions that each have an owner, a date and an approver. Then share what you learned.

The distributor didn't need a more careful coordinator. It needed a checklist and a second pair of eyes.

Run your next post-mortem without a designated note-taker. ParrotNotes captures the conversation in the room and hands you the summary and action items. Download ParrotNotes free.