Observability and reliability
Action items that get finished
Good action items are specific, owned, prioritized and dated. Tracking them is what turns a postmortem into an actual fix.
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
| Vague | Specific |
|---|---|
| "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
| Priority | Example | Owner | Due |
|---|---|---|---|
| P0 | Canary fails the rollout if payments success drops more than 0.5% for 2 minutes | Maya | Friday |
| P1 | Add ±10% jitter to the product-cache TTL | Dev team | This sprint |
| P2 | Runbook section: "cache stampede: shed load, then warm" | On-call lead | 2 weeks |
| P3 | Talk on coordinated omission in load tests | Platform | Next 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
- 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.
- 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
Related
Blameless postmortems
Learning from failure with timelines, contributing factors and action items that actually get done — without turning people into the root cause.
Owning your code in production
On-call, alerts, runbooks, and the loop that makes you trustworthy — and better at building systems that survive users.
Contributing factors, not a single root cause
Complex failures come from several causes that combine. List factors by category, and do not stop at the first person, because that fixes nothing.