Guide

A postmortem without finished follow-ups is theater. Vague items such as "improve monitoring" or "be more careful" sound responsible and then die in the backlog. A useful action item names one change, one owner, a priority and a due date.

Concept

Before you start. Read contributing factors. Each action item should answer one factor.

Vague or specific

VagueSpecific
"Improve monitoring""Add a canary that fails the rollout if the payments success rate drops by more than 0.5% for 2 minutes"
"Be more careful with cache TTLs""Add exponential jitter to the product-cache TTL (±10%)"

The specific version can be built, tested and checked. The vague one can only be argued about.

A priority table

PriorityExampleOwnerDue
P0Canary fails the rollout if payments success drops more than 0.5% for 2 minutesMayaFriday
P1Add ±10% jitter to the product-cache TTLDev teamThis sprint
P2Runbook section: "cache stampede: shed load, then warm"On-call lead2 weeks
P3Talk on coordinated omission in load testsPlatformNext month

Rules of thumb

  • One owner. A person, not "the team." A team cannot answer "is it done?"
  • Prefer removing a class of failure. Automation and safer defaults beat "train harder."
  • Cap the critical list. Ten P0 items means none are critical.
  • Track them with product work. Review open items every week until each is closed or marked won't-fix with a reason.
  • Separate process from projects. A threshold tweak and a billing rewrite stall each other if they share a list.

Trade-off

A quick patch stops the bleeding this week, such as a feature flag, a tighter alert or automatic rollback. A structural fix needs a real milestone. Only patches guarantee a repeat. Only structural work leaves you exposed in the meantime.

Common mistakes

  • Writing vague, virtuous items. Replace "be careful" with a check that runs automatically.
  • Too many P0s. Priority only works if it is scarce.
  • Mixing small process fixes with big projects. Both stall.

Check yourself

  1. Which is the stronger action item: "be more careful with deploys" or "block deploys that have no canary"? Answer: the second. It removes the failure path instead of relying on people to remember.
  2. Why one owner instead of a team? Answer: a team cannot be asked in a weekly review whether an item is done, so the item drifts.

Key takeaways

  • Each action item is one change, with one owner, a priority and a date.
  • Prefer changes that remove a failure class over changes that ask people to try harder.
  • Keep the critical list short, and review it every week.
  • Next, sharing learnings explains how to spread the lessons.

Further learning

Postmortem Practices for Incident Management (Google SRE Workbook)SRE postmortem practices for documenting incidents, understanding root causes, and preventing recurrence. Explore blameless postmortemculture and best practices.sre.google PagerDuty Postmortem DocumentationA collection of information about the PagerDuty postmortem process and industry best practices. This guide will teach you how to build a culture of continuous learning, the most important components to include in your…PagerDuty Postmortem Documentation Incident Postmortem: Process and Best Practices (Atlassian)An incident postmortem is a blameless review of what happened in an incident, why, and how to prevent it recurring. See the process and best practices.Atlassian