The 2025 Guide to Running Successful Post Mortem Meetings: Best Practices & Free Template

TL;DR: Post-Mortem Meeting Guide

This guide shows you how to run post-mortem meetings that actually work. Learn when a formal post-mortem is necessary (and when it isn't), follow a 6-step process to find the real root cause, and use proven templates to ensure your learnings turn into concrete action items.

‍

What Is a Post-Mortem Meeting?

A post-mortem meeting is a structured, blameless discussion held after an incident, outage, or project completion to analyze what happened and why. The goal is to create a shared understanding of the event and produce concrete, actionable steps to prevent repeat failures and improve future performance. It’s a foundational process for any team focused on learning from both their successes and failures.

Benefits of a Healthy Post-Mortem Culture

A well-run post-mortem is more than just a recap—it’s a powerful tool for continuous improvement. One of the biggest benefits is improved team communication; when everyone has a chance to share their perspective in a safe environment, it increases transparency and builds trust. By focusing on learning, your team can develop actionable plans that lead to more reliable systems, a more effective engineering process, and ultimately, better outcomes.

‍

Do You Always Need a Post-Mortem?

Not all incidents are created equal, and your response shouldn’t be either. A minor hiccup doesn’t require the same deep-dive analysis as a site-wide outage. The key is to match the effort of the review to the severity of the impact.

Here’s a practical guide to deciding if—and how—you should conduct a post-mortem.

SEV-0 / SEV-1: Critical & Major Incidents(e.g., Site-wide outage, major data corruption, SLA breach)

Verdict: Yes, always. A full, formal post-mortem is non-negotiable.These are your most expensive and painful incidents and, therefore, your most valuable learning opportunities. A rigorous review is mandatory for internal learning and for maintaining customer trust.

• Process: A synchronous, facilitated meeting with all key stakeholders is required.
• Output: A comprehensive, written report must be created and shared widely to ensure key insights are utilized for process improvements.
• Participants: Invite a broad group, including the engineers who worked the incident, on-call responders, customer support leads, and product and engineering leadership.

SEV-2 / SEV-3: Minor & Low-Impact Incidents(e.g., A transient error spike, a failed deployment that was instantly rolled back)

Verdict: Usually not. Focus on lightweight, automated tracking.Forcing a formal meeting for every minor issue leads to “post-mortem fatigue.” The goal here isn’t a deep investigation but signal detection. Are these minor incidents happening frequently?

• Process: Skip the meeting. Instead, rely on your tooling to capture the essential data to help spot recurring issues.
• Output: The incident should still be formally logged in a tool like Rootly, which can automatically capture the timeline, resolution, and any alerts that fired. If the same minor incident occurs multiple times, that pattern itself should trigger a more formal review.
• Participants: No dedicated meeting attendees are needed.

‍

‍

‍

A Step-by-Step Guide to Running the Meeting

A well-facilitated meeting follows a clear structure. Preparing talking points in advance helps guide the discussion and keeps the meeting focused on the most important topics.

1. Set the Stage

Your first job as a facilitator is to break the tension. Acknowledge the stress of the incident, thank the team for their work, and immediately state the ground rule: “We’re here to understand our system’s weaknesses, not to find someone to blame.” Appoint your dedicated notetaker, and ensure everyone has access to the agenda and any preliminary reports.

How Rootly Helps: You can skip the painful scramble for context. Rootly pieces together the entire story for you—every alert, Slack message, and timeline event—into a clean brief you can send out beforehand.

2. Walk Through the Timeline

Your goal is to create a shared, factual understanding of the sequence of events. Have the Incident Commander or a key responder narrate a concise timeline, covering detection, escalation, key mitigation actions, and final resolution.

How Rootly Helps: This step is drastically simplified with an incident management platform. Rootly's AI automatically generates a detailed timeline, turning hours of manual work into a one-click action.

3. Identify What Went Well

Before you jump into what broke, take five minutes to talk about what didn’t. Was an alert particularly helpful? Did a runbook save the day? Acknowledging what worked isn’t just for morale; it’s how you identify and reinforce reliable processes. Then, ask the most important question: “Where did we get lucky?” Uncovering where you almost had a much bigger disaster is pure gold for preventing future incidents.

4. Analyze Failures and Gaps

This is the core of the meeting. Guide the team through a root cause analysis using targeted questions to uncover underlying issues. The “5 Whys” technique is a simple but powerful tool to move past symptoms to systemic causes. Remember to keep the focus on process gaps, tooling blind spots, or areas of unclear ownership—not on individual blame.

How Rootly Helps: Rootly’s AI surfaces root-cause insights by analyzing incident data and suggesting contributing factors, helping your team get to the heart of the matter faster.

5. Define Action Items

This is where most post-mortems fall apart. Don’t end with a vague list of “things we should do.” For every issue, create a concrete task and assign it to a single person. Ask them directly: “Can you get this done, or do we need to make it a bigger project for the next sprint?” This public commitment turns a fuzzy idea into accountable work.

How Rootly Helps: Capture action items directly within Slack. Rootly’s native integration with Jira, Linear, and ServiceNow allows you to create and assign tickets instantly, ensuring nothing gets lost.

6: Finalize the Notes and Spread the Knowledge

The work isn’t done until the lessons are shared. Distill the raw notes from the meeting into a clean, easily digestible report. The goal is to ensure the pain of this incident benefits the entire organization, so actively push key learnings out. Pull out the finding about the monitoring gap and send it to the observability team. Share notes on a confusing workflow with the right product manager.

How Rootly Helps: Rootly builds the report in the background, automatically assembling the timeline, participants, and action items. Finalizing the report becomes a 10-minute task of cleaning up notes, not a multi-hour writing assignment.

‍

‍

Free Post-Mortem Meeting Template

• Template from Site Reliability Engineering book
• Template from The Practice of Cloud System Administration book
• Template from Google Developers Blog post
• Template from Azure status history posts
• Template from Michael Kehoe's blog post
• Template from the Real-World SRE book
• Template from Elastic Cloud incident report‍
  

Examples

• Google Compute Engine Incident #16007
• Azure status history
• Buildbucket Postmortem: 6% builds lost on 2015-04-22
• Google API infrastructure outage incident report
• Gitlab - Postmortem of database outage of January 31
• Summary of the Amazon DynamoDB Service Disruption and Related Impacts in the US-East Region
• Elastic Cloud Incident Report: February 4, 2019

‍

FAQs

1. What is the purpose of a post mortem meeting? The primary goal is to uncover what went wrong, what went right, and how to prevent future incidents—without assigning blame. It’s about improving the system, not pointing fingers.
2. What is another name for post mortem meeting? A "post-mortem meeting" can also be called a retrospective, lessons learned meeting, after-action review (AAR), or debrief.
3. Who typically runs a post-mortem meeting?Usually, the incident commander, SRE lead, or project manager facilitates the session. They guide the discussion, enforce psychological safety, and ensure follow-ups are assigned.
4. How soon should I host a post-mortem meeting after an incident?Ideally within 24–72 hours of resolution—while memory is fresh but emotions have cooled.
5. What should a post-mortem report include?A complete report must include a summary of the business and customer impact, a detailed timeline of events, a root cause analysis, and, most importantly, a list of specific action items with clear owners and due dates.
6. How do you keep a post-mortem meeting blameless?The facilitator must set the tone by stating the blameless principle at the start and actively redirecting blame-oriented language. Focus the conversation on systemic failures ("the process allowed for an error") rather than individual actions ("your code caused the error").
7. How do you ensure action items are actually completed?Treat action items like any other engineering task by creating tickets for them in your project management system (e.g., Jira, Linear). Assigning each item to a specific owner with a deadline makes follow-through visible and holds the team accountable.