After something goes wrong, like an outage, a big bug, or a system failure, I like to sit down with the team and talk about what happened.
That’s what a post-mortem meeting is. It’s not about blaming anyone.
Running a post-mortem helps me and my team understand what went wrong, what worked well, and what we can do better next time.
These meetings are super helpful, especially if you’re part of an engineering, operations, or SRE team that deals with incidents.
I’ve seen people worry that post-mortems turn into blame games. That shouldn’t happen. A good post-mortem feels safe.
Everyone can speak honestly, and the focus stays on fixing systems, not pointing fingers.
I’ll walk you through how to run a post-mortem meeting step by step, so your team can learn, improve, and bounce back stronger.
What Is a Post-Mortem Meeting?
A post-mortem meeting is a team discussion that happens after something goes wrong, like a system outage, a bug, or a failed update.
The main goal is to understand what caused the problem and how to stop it from happening again.
In incident management, post-mortems focus on one specific issue. The team looks at when the problem started and what could have been done better.
This is different from a retrospective, which reviews how the team worked during a full project or sprint. A post-mortem is more about one incident and how to learn from it.
These meetings help the team take responsibility, learn new things, fix broken steps, and make the system stronger.
Most importantly, post-mortems are not about blaming people; they are about working together to improve.
When to Conduct a Post-Mortem Meeting
Post-mortem meetings should happen after serious problems or repeated issues. Knowing when to run one helps teams learn and prevent future trouble.
- After major incidents: Run a post-mortem after big problems like P0/P1 issues, system outages, or critical bugs.
- When businesses are affected: If the issue causes downtime, customer impact, or data loss, it’s worth reviewing.
- Within 24–72 hours of fixing the issue: Schedule the meeting soon after the problem is solved, while the details are still fresh.
- For repeated problems: If the same type of issue keeps happening, do regular post-mortems to find the root cause.
- Even for smaller issues: If a small issue shows signs of becoming a bigger one, it can be helpful to review it early.
- When process changes are needed: Use post-mortems to improve communication, tools, or workflows, especially if something felt off during the response.
How to Prepare for a Post-Mortem Meeting
Before the post-mortem meeting, get all the important details ready. This helps the team understand the main problem.
- Gather key information: Collect logs, system metrics, a clear timeline, and any reports about how users were affected.
- Use a standard template: A post-mortem template helps organize the meeting. Include sections like timeline, causes, what worked, what didn’t, and action items.
- Prepare answers to key questions: What happened, why did it happen, what went well, what went wrong, how can you prevent this in the future.
- Notify participants early: Let everyone know about the meeting ahead of time.
- Share materials before the meeting: Send the timeline, notes, and data so the team can review them and come prepared.
How to Conduct a Post-Mortem Meeting
Running the post-mortem meeting the right way helps the team learn and improve. Each step should be clear, calm, and focused on solving problems, not blaming people.
Step 1: Set the Tone
Start the meeting by creating a safe space. Make it clear that the goal is to learn, not to blame anyone.
Explain the purpose of the meeting to understand the incident and find ways to do better next time. Let the team know what outcomes are expected, like clear action items.
Step 2: Walk Through the Timeline
Go over the incident step by step. Begin with when the issue first started, who noticed it, and how it got worse.
Talk through each major moment, including alerts, responses, fixes, and any delays. This helps everyone get on the same page and see how things unfolded in real time.
Step 3: Identify Root Causes
Use tools like the “5 Whys” or a fishbone diagram to find out what really caused the problem. Don’t stop at surface-level answers.
Look deeper to find the root cause. Also, talk about things that made the problem worse, even if they didn’t directly cause it. These are called contributing factors.
Step 4: Discuss What Went Well
Take a moment to highlight the good parts. Maybe someone responded quickly, or backup systems worked well.
Good communication or teamwork should also be noted. This helps boost team morale and shows what’s working.
Step 5: Discuss What Could Be Improved
Now look at what didn’t go well. Were there delays in response? Were alerts missing or unclear? Was it hard to know who was in charge?
Talk about any tools or processes that didn’t help or even made things harder. Keep the focus on fixing, not blaming.
Step 6: Define Action Items
List out clear tasks to fix the problems found. Each action should be specific, measurable, assigned to a person, and have a due date.
For example: “Add alert for X condition by next Friday assigned to Jane.” This makes sure the fixes actually happen.
Step 7: Confirm Next Steps and Ownership
Before ending the meeting, review who is responsible for each task and when updates will be shared.
Decide if there will be a follow-up meeting or review. This keeps things moving and helps the team stay accountable.
Check out this short video that walks through the process step by step by @teamgantt
What Steps Should You Take After a Post-Mortem Meeting?
The post-mortem meeting isn’t the end, it’s the start of real improvement. After the meeting, it’s important to follow through on the next steps.
- Share the post-mortem report: Send the report to all team members and stakeholders so everyone knows what was discussed.
- Track action items: Make sure each task is being worked on and nothing is forgotten.
- Review progress later: Check in during the next sprint, planning, or team meeting to see if the fixes were done.
- Save the report for future use: Archive it in a shared folder and add tags so it’s easy to find if a similar issue happens again.
- Update team runbooks: If the post-mortem led to a process change, update internal guides or checklists.
- Review if the problem is truly solved: After a few weeks, check if the issue has been fixed or if more work is needed.
Conclusion
I’ve learned that doing post-mortems the right way makes a big difference.
They help teams understand what went wrong, why it happened, and how to stop it from happening again.
When a problem hits, it’s easy to move on quickly, but I’ve found that slowing down to talk about it helps everyone learn and grow.
One thing I always try to do is keep the meeting blameless. It’s not about who made the mistake.
It’s about how the system failed and what we can do better next time. When people feel safe to speak up, we get honest answers and better solutions.
I don’t believe a post-mortem has to be perfect.
Even small changes like clearer alerts or better communication can make the system stronger.
Over time, these meetings help teams become more confident, more prepared, and more connected. And that’s what makes the effort worth it.
