Post-Mortem & Root Cause Analysis

Overview

Post-mortems (also called Post-Incident Reviews or Root Cause Analysis) are structured reflections that help teams learn from incidents, identify root causes, and prevent recurrence. Sizemotion provides a comprehensive post-mortem system with:

• Structured templates with seven key sections
• Action item tracking with owners, priorities, and due dates
• Automatic metrics calculation (MTTR, MTTA)
• Draft/publish workflow for collaborative editing
• Activity feed integration for visibility

When to Create a Post-Mortem

Create a post-mortem for incidents that are:

• Resolved or Cancelled (required status)
• High severity (Critical or High priority incidents)
• Impactful (affected customers or services)
• Educational (valuable lessons for the team)
• Recurring (patterns that need addressing)

Access Post-Mortem Editor

1. Navigate to the incident detail page
2. Ensure incident status is Resolved or Cancelled
3. Click "Create Post-Mortem" button (top-right)
4. Or click "Edit Post-Mortem" if one exists

Post-Mortem Structure

Each post-mortem follows a proven 7-section template:

1. Summary

One-paragraph overview. Briefly describe what happened, the impact, and the resolution. This should be readable by non-technical stakeholders.

2. What Happened

Detailed timeline of events. Chronological account from detection to resolution, including key actions taken and their outcomes.

3. Root Cause

The fundamental reason(s) for the incident. Use the "5 Whys" technique to drill down. Avoid blaming individuals—focus on systems, processes, and tools.

4. Impact Assessment

Quantify the damage. Include metrics like:

• Number of affected users or services
• Duration of degradation or outage
• Revenue impact (if applicable)
• Customer-reported issues

5. What Went Well

Celebrate successes. Acknowledge what worked: rapid detection, effective communication, clever workarounds, or teamwork under pressure.

6. What Could Be Improved

Identify gaps without blame. What processes, tools, or documentation would have helped? What slowed down the response?

7. Lessons Learned

Key takeaways. Distill the incident into actionable insights that can be shared across teams.

Action Items Management

Post-mortems are only valuable if they drive change. Sizemotion includes built-in action item tracking with full CRUD operations.

Creating Action Items

From the post-mortem editor sidebar:

1. Scroll to "Action Items" section
2. Fill in the form:
   • Title (required) - Brief description
   • Description (optional) - Detailed context
   • Owner - Team member responsible
   • Due Date - Target completion date
   • Priority - High / Medium / Low
3. Click "Add Action Item"

Managing Action Items

Each action item displays with quick actions:

• ✓ Complete - Mark as done with one click
• ↻ Reopen - Return completed items to pending
• ✎ Edit - Update all fields via modal
• 🗑 Delete - Remove the action item

Status Values

Status	Meaning	Badge Color
Pending	Not yet started	Gray
In Progress	Actively being worked on	Blue
Completed	Finished successfully	Green
Cancelled	No longer needed	Dark

Priority Levels

• High Priority - Critical fixes, must be addressed immediately
• Medium Priority - Important improvements, address soon
• Low Priority - Nice-to-have enhancements, backlog items

Metrics & Timeline

Sizemotion automatically calculates incident response metrics from your timeline:

MTTA (Mean Time to Acknowledge)

Time from incident creation (created_at) to first acknowledgment (acknowledged_at). Measures detection and initial response speed.

MTTR (Mean Time to Resolve)

Time from incident creation (created_at) to resolution (resolved_at). Measures overall incident lifecycle duration.

Timeline Events

Add custom timeline events to document key moments during the incident:

• When the issue was first detected
• When mitigation started
• When services were restored
• When root cause was identified

Timeline events appear chronologically in the published post-mortem and provide context for understanding the incident flow.

Publishing & Sharing

Draft vs. Published

Post-mortems have two states:

• Draft - Editable, not visible in activity feed, work-in-progress
• Published - Read-only view, broadcasted to activity feed, permanent record

Publishing a Post-Mortem

1. Complete all required sections
2. Add relevant action items with owners
3. Review metrics and timeline
4. Click "Save & Publish" button

Once published, a post-mortem:

• Appears in the activity feed for all team members
• Displays in read-only mode at the incident detail page
• Shows action item progress with completion tracking
• Can still have action items edited (mark complete, update status, etc.)

Editing Published Post-Mortems

While the post-mortem content becomes read-only after publishing, you can still:

• Update action item status (complete/reopen)
• Edit action item details (owner, due date, priority)
• Delete action items
• Add new action items

Best Practices

Blameless Culture

Post-mortems should focus on systems and processes, not individuals. Avoid phrases like "John caused the outage" and instead say "insufficient monitoring allowed the issue to go undetected."

Timely Completion

Create post-mortems within 48 hours of incident resolution while details are fresh. Assign a DRI (Directly Responsible Individual) to coordinate.

Actionable Follow-ups

Every post-mortem should have at least one action item. Even if it's "document the workaround" or "add monitoring for X." Make improvements concrete.

Share Broadly

Publish post-mortems to your team's activity feed. Learning should be shared, not siloed. Consider scheduling post-mortem review meetings for high-impact incidents.

Track Completion

Review action items in weekly standups or incident retrospectives. Update statuses regularly. Overdue items signal process gaps that need attention.

Iterate on Templates

The 7-section template is a starting point. Adapt it to your team's needs. Add custom sections in the description fields if needed.