Postmortem Action Prioritizer
Prioritize incident postmortem action items using impact vs. effort analysis. Focus remediation efforts on high-ROI improvements.
Formula
Priority Score = (Impact × 0.5) + ((10 - Effort) × 0.3) + ((10 - Time/5) × 0.2); Tier: P0 if Priority ≥ 7, P1 if ≥ 5.5, P2 if ≥ 4, else P3
The formula weights impact (50%), inverse effort (30%), and urgency based on implementation time (20%). Impact matters most because the goal is risk reduction. Effort is inverted so lower effort scores higher—easier actions are prioritized among similar-impact items. Implementation time provides urgency context. The formula produces priority scores that map to P0-P3 tiers, creating clear actionability. This approach works because it balances effectiveness against feasibility, preventing perfect-is-enemy-of-good while ensuring high-impact items aren't ignored due to effort.
Worked Examples
Example 1: Database Outage
Problem:2-hour database failure. 8,000 customers affected, $50,000 revenue lost. 6 action items identified.
Solution:Quick wins: Add query monitoring (impact 7, effort 3). Major: Implement automated failover (impact 10, effort 13). Prioritize monitoring first for fast win.
Result:6 actions prioritized | 2 quick wins | 1 major project | 45 dev-days total
Example 2: API Rate Limit Incident
Problem:30-min API unavailability due to rate limit. 500 users affected, $2,000 impact. 4 actions.
Solution:Top priority: Rate limit monitoring (impact 9, effort 2, 3 days). Also: Better error messages (impact 6, effort 3). Skip expensive API redesign (impact 5, effort 20).
Result:4 actions | Focus on monitoring | Skip low-ROI redesign | 15 dev-days
Example 3: Deployment Gone Wrong
Problem:Bad deploy took down site for 45 min. 12,000 users affected. 8 proposed actions.
Solution:Too many actions (8). Consolidate to: Enhanced deployment gates (impact 9, effort 5), Rollback automation (impact 10, effort 8), Canary deployment (impact 8, effort 13).
Result:8 → 3 focused actions | Top 3 address root causes | 26 dev-days
Frequently Asked Questions
What is a postmortem?
A postmortem (or post-incident review) is a blameless analysis conducted after an outage or incident. It documents what happened, why, and what actions will prevent recurrence. Blameless culture enables honest learning.
How do I prioritize postmortem action items?
Use impact (how much does this reduce future risk?) vs. effort (how hard to implement?). High impact, low effort are quick wins. High impact, high effort need planning. Low impact items may not be worth doing.
What's a reasonable number of action items?
3-7 actionable items per postmortem. More than 10 suggests too little prioritization—most won't get done. Focus on high-impact items that actually get implemented.
Should every postmortem have action items?
Not necessarily. If existing defenses worked or the incident was truly unforeseeable, acknowledge it. Manufacturing action items creates busy work. Sometimes the lesson is 'our systems worked as designed.'
How do I track postmortem action completion?
Assign owners, set due dates, track in project management tools (Jira, Linear, etc.). Review quarterly—incomplete actions from old postmortems indicate follow-through problems.
What makes a good postmortem action item?
Specific (not vague), measurable (can verify completion), achievable (realistic scope), relevant (actually prevents recurrence), and time-bound (has deadline). Avoid 'improve monitoring'—specify what metrics.
Should postmortems be public?
Internal: always. External: for customer-facing incidents, transparency builds trust. Startups often publish detailed postmortems. Regulated industries may limit disclosure. Balance transparency with legal/competitive concerns.
Who should attend postmortems?
People involved in the incident (responders, on-call), relevant technical experts, and stakeholders (product, support). Keep it under 10 people for productive discussion. Distribute notes widely afterward.
How long should a postmortem take?
1-2 hours for typical incidents. Complex incidents may need longer. Schedule within a week of resolution while memory is fresh. Preparation (timeline, data) happens beforehand.
What if the root cause is organizational?
Many incidents have org root causes: understaffing, rushed releases, inadequate training. These are hardest to fix but most important. Escalate to leadership—some fixes require executive decisions.
Background & Theory
Postmortem action prioritization applies systematic scoring to incident follow-ups, ensuring high-impact improvements are implemented while avoiding action item overload.
Concept Overview
Postmortems generate many potential actions. Prioritization determines what actually gets done. Impact (how much does this reduce future risk?) versus effort (how hard to implement?) creates a 2×2 matrix with clear priorities.
Quick wins (high impact, low effort) should be done immediately. Major projects (high impact, high effort) need planning. Low-impact items may not justify resources regardless of effort.
Key Variables & Intuition
- Impact score — Risk reduction potential (1-10)
- Effort score — Implementation difficulty (1-10)
- Time to implement — Calendar days/developer-days
- Incident severity — Context for urgency
- Resource availability — Capacity for implementation
Assumptions
- Impact scores are reasonable estimates
- Resources exist for high-priority items
- Actions are independent (can be done separately)
- Impact is persistent (benefit continues)
Limitations & Edge Cases
- Interdependencies — Some actions depend on others
- Organizational barriers — Some actions need executive buy-in
- Resource constraints — Limited capacity affects what's feasible
- Urgency vs. importance — Some low-impact items may be urgent
Scenario: A postmortem identifies that inadequate staffing contributed to slow response. The action "hire 2 SREs" has high impact but is outside the team's control. Escalate to leadership rather than marking as "incomplete action item."
Interpretation Guide
Priority Tiers:
- P0 Critical: Do first, often immediately
- P1 High: Schedule within 1-2 sprints
- P2 Medium: Backlog for next quarter
- P3 Low: Consider but may not do
Impact Assessment:
- 8-10: Would prevent recurrence
- 5-7: Reduces likelihood significantly
- 2-4: Marginal improvement
- 1: Negligible benefit
Practical Tips
- Focus on prevention, not blame — Blameless culture enables learning
- Limit action items — 3-7 high-impact actions beat 20 mediocre ones
- Assign clear owners — Unowned actions don't get done
- Set realistic deadlines — Match capacity and urgency
- Track completion — Review quarterly
- Learn from patterns — Recurring themes indicate systemic issues
Common Mistakes
- Too many action items — Dilutes focus; most don't get done
- Vague actions — "Improve monitoring" isn't actionable
- No owners — Everyone's responsibility is no one's
- No follow-up — Action items documented but forgotten
- Blame culture — Prevents honest analysis
- Treating symptoms, not causes — Quick fixes that don't address root issues
When NOT to Use
- True one-offs — Freak accidents may not warrant extensive action
- Actions already in progress — Don't duplicate existing work
- Issues outside control — Some problems require vendor or platform changes
History
Postmortem practices evolved from aviation accident investigation through healthcare safety models to DevOps blameless retrospectives.
Origins & Why It Emerged
Aviation pioneered systematic incident analysis. Every crash was investigated thoroughly. The focus was learning, not blame—discovering systemic issues that could prevent future accidents. The NTSB model became gold standard.
Healthcare adopted similar approaches. Medical errors killed thousands annually. The Institute of Medicine report (1999) emphasized that most errors had system causes, not individual fault. Blame prevented learning.
Software incident postmortems emerged in the 2000s. Google SRE practices formalized blameless postmortems. Etsy made them public. The DevOps movement spread the practice widely.
How It Evolved in Practice
Early incident reviews often sought blame. "Who broke production?" This created fear and hiding. People covered up mistakes rather than learning from them.
Blameless postmortems changed culture. "How did the system allow this to happen?" shifts focus from individuals to process. This psychological safety enables honest discussion.
Action item tracking evolved. Initially, action items were documented but forgotten. Modern practice includes tracking, accountability, and quarterly reviews of completion rates.
Modern Usage Today
Modern postmortems are structured processes. Templates guide analysis. Tools (incident.io, PagerDuty) manage the workflow. Postmortem databases enable pattern recognition across incidents.
Machine learning analyzes postmortems. Common themes, recurring issues, and effectiveness of past action items inform future priorities. The corpus of postmortems becomes institutional knowledge.
Common Misconceptions Historically
- Postmortems assign blame — Blameless is core to learning
- Action items must all be done — Prioritize; some items aren't worth effort
- Root cause is singular — Most incidents have multiple contributing factors
- Postmortems prevent recurrence — They reduce likelihood but can't eliminate all risk
- Only major outages need postmortems — Near-misses and small incidents offer learning too