Post mortem meeting template (blameless, free)

What’s in the template

The minutes open with these details:

• Incident or project name
• Reference (incident ID or project code)
• Date of incident (or project end date)
• Date of this meeting
• Facilitator
• Scribe
• Present (name, team)
• Severity (per your organisation's scale)
• Report status (draft / reviewed / final)
• Audience (internal only / shareable with customers)

Then the body follows the meeting in this order:

1. 1. Ground rules — Read the blameless statement aloud: the purpose is to learn; everyone acted reasonably on what they knew at the time; we describe systems and conditions, not people.
2. 2. Summary — Two or three sentences a senior manager could read on their own.What happened: · Duration (first impact to full recovery): · Detected by: · Resolved by:
3. 3. Impact — Numbers wherever possible. Estimates are fine if marked as estimates.Customers or users affected: · Orders, revenue or transactions affected: · Internal effort (people-hours): · Contractual or SLA effect: · Public communication sent (when, where):
4. 4. Timeline — Timestamped, in one timezone, from the first contributing change to full recovery. Mark detection, escalation, mitigation and resolution. Build it from logs, alerts and chat before the meeting; agree it in the meeting.Time: · Event: · Source (alert, log, person):
5. 5. Root causes and contributing factors — There is rarely one cause. For each, say how it contributed and why it was not caught earlier. Ask why until the answer is a process or a design, not a person.Cause: · How it contributed: · Why it was not caught earlier:
6. 6. What went well — Things that limited the damage: alerts that fired, a runbook that worked, a quick decision.
7. 7. What went wrong — Things that made it worse or slower: a missing test, a rollback that failed, a page that reached the wrong person.
8. 8. Where we got lucky — Things that would have made it worse and did not, by chance. These are live risks and need actions too.
9. 9. Action items — Each with an owner and a date. Label each as preventing recurrence, detecting faster or reducing impact. Fewer actions that will be done beat many that will not.Action: · Type (prevent / detect / mitigate): · Owner: · Due:
10. 10. Review and distributionReviewed by: · Date: · Shared with:

At the end: timeline and action items, as tables you can keep across meetings.

The template

Download it as a Word file, or copy the text version into your own document.

Post Mortem Report

Incident or project name: 
Reference (incident ID or project code): 
Date of incident (or project end date): 
Date of this meeting: 
Facilitator: 
Scribe: 
Present (name, team): 
Severity (per your organisation's scale): 
Report status (draft / reviewed / final): 
Audience (internal only / shareable with customers): 

1. Ground rules
   [Read the blameless statement aloud: the purpose is to learn; everyone acted reasonably on what they knew at the time; we describe systems and conditions, not people.]

2. Summary
   [Two or three sentences a senior manager could read on their own.]
   What happened:
   Duration (first impact to full recovery):
   Detected by:
   Resolved by:

3. Impact
   [Numbers wherever possible. Estimates are fine if marked as estimates.]
   Customers or users affected:
   Orders, revenue or transactions affected:
   Internal effort (people-hours):
   Contractual or SLA effect:
   Public communication sent (when, where):

4. Timeline
   [Timestamped, in one timezone, from the first contributing change to full recovery. Mark detection, escalation, mitigation and resolution. Build it from logs, alerts and chat before the meeting; agree it in the meeting.]
   Time:
   Event:
   Source (alert, log, person):

5. Root causes and contributing factors
   [There is rarely one cause. For each, say how it contributed and why it was not caught earlier. Ask why until the answer is a process or a design, not a person.]
   Cause:
   How it contributed:
   Why it was not caught earlier:

6. What went well
   [Things that limited the damage: alerts that fired, a runbook that worked, a quick decision.]

7. What went wrong
   [Things that made it worse or slower: a missing test, a rollback that failed, a page that reached the wrong person.]

8. Where we got lucky
   [Things that would have made it worse and did not, by chance. These are live risks and need actions too.]

9. Action items
   [Each with an owner and a date. Label each as preventing recurrence, detecting faster or reducing impact. Fewer actions that will be done beat many that will not.]
   Action:
   Type (prevent / detect / mitigate):
   Owner:
   Due:

10. Review and distribution
   Reviewed by:
   Date:
   Shared with:

Timeline
Time | Event | Source

Action items
No. | Action | Type | Owner | Due | Status

Example: filled-in post mortem meeting

What the template looks like once it’s been used. The organisation and people are made up.

Action items

Tips for post mortem meeting

• Hold the meeting within a week of the incident, after the timeline is drafted but before memories blur.
• Send the draft timeline to attendees the day before and ask them to correct it in writing. The meeting then starts from an agreed sequence.
• Have someone who was not involved in the incident facilitate. The people who fixed it should be free to talk.
• Label each action as prevent, detect or mitigate. If all your actions are prevent, you have not thought about the next incident, which will be different.
• Track post mortem actions in the same place as other work, with the incident reference, and review open ones at the next post mortem.
• Write the customer-facing summary from the final report, not before it; the two must not disagree.

Related templates

• Sprint retrospective template — What went well, what didn't, ideas, and the one to three actions the team actually commits to.
• Project meeting minutes template — The weekly status record: where each workstream stands, which milestones moved, what changed on the risk log and what was decided.
• Safety committee minutes template — The monthly safety committee record: incidents, near-misses, inspections, hazard reports and a corrective actions register that stays open until verified.
• Meeting notes with action items template — Notes built around a running action register, for recurring meetings where last week's actions are this week's first agenda item.
• All meeting minutes templates

Or let the notes write themselves

A template helps when you’re the one typing. If you’d rather not be, an AI note taker can draft the summary and action items for you. Most send a bot into the call; QuietNote captures from your own computer instead, so nothing joins the meeting and you decide when capture starts. It’s in private beta. Whatever you use, read the draft before you send it, and tell attendees you’re recording where the rules require it.