Why do most postmortem action items never get done?

Because they are written without an owner, without a date, and without anything that forces someone to check on them later. Google's own SRE team, after reviewing thousands of internal postmortems, named lack of follow-up as the most common failure in the whole process, and traced it to action items that were never assigned to a person.

What is the single biggest fix for postmortems that change nothing?

Assign a named owner and a date to every action item before the meeting ends. Google's SRE guidance states it plainly: the surest way to guarantee an action item never gets completed is to leave it without an owner, because an item that belongs to everyone belongs to no one in practice.

Who should own a postmortem action item, the person who caused the incident?

No. Ownership is an administrative role, not a punishment or an admission of fault. The owner makes sure the item gets finished, whether that means doing the work themselves or making sure the right person does, and a blameless postmortem assigns ownership on exactly that basis.

What makes an action item well written versus vague?

Google's SRE team describes three properties: actionable (it starts with a verb and produces an outcome, not a process), specific (its scope is narrow enough that everyone agrees what counts as done), and bounded (there is a clear condition under which it is finished). "Investigate the timeout" fails all three; "add a five-second timeout and a retry with backoff to the payment call" passes.

Should every postmortem action item get fixed immediately?

No. Some items require real design work and cannot fit into the days right after an incident. The mistake is treating every item the same way, with no priority and no distinction between what must happen before the next incident and what can happen next quarter.

What should happen to an action item that never gets done?

Either it gets closed as no longer relevant, or it stays open and visible on a list someone actually looks at. What should never happen is for it to quietly disappear from view, because an invisible open item is functionally the same as one that was never written.

How often should a team revisit its list of open action items?

On a fixed schedule, rather than only when someone remembers. A regular weekly or biweekly review of everything still open, with the owner and date visible next to each line, is what turns a list of good intentions into a list that actually shrinks over time.

Does writing detailed postmortems by itself improve reliability?

Not on its own. A postmortem that documents the incident well but produces no completed action items leaves the system exactly as capable of failing the same way again. The postmortem explains the problem, and the action items, once finished, fix it.

How does this apply to a team using AI to write more code, faster?

A higher rate of change tends to produce a higher rate of incidents, so the list of proposed action items grows faster too. Without an owner and a date on each one, that list grows beyond what any team can actually finish, and the postmortem process turns into paperwork nobody reads.

How to write a postmortem that changes behaviour: Reveneau

Q: How long should a team have to fix a high-priority action item?

There is no universal number, but PagerDuty's incident response documentation recommends completing action items tied to a severity-1 incident within 15 days, and items tied to a severity-2 incident within 30 days. A specific date, with someone accountable to it, is what makes the item real.

We have sat in postmortem meetings that ran well. The timeline was accurate, the root cause was named without anyone getting defensive, and the group agreed on three things to fix. Then, weeks later, the same document turns up again for a different incident with the same underlying cause. The meeting worked, and then nobody finished the fixes.

That gap is common, and it comes down to one thing: what happens to the list of action items after the meeting ends. Here is the method that fixes it: assign every item to one named owner, attach a real date, and revisit the open list on a fixed schedule rather than whenever someone remembers to.

The list of changes is what matters

A postmortem is a written record of what broke, why, and what should change so it does not break the same way twice. That third part, the list of changes, is the only piece of the document that affects the future. Everything before it explains the problem.

Google's own SRE team, writing about the practice after reviewing thousands of internal postmortems, described the most common failure plainly: "the most common shortcoming is lack of follow-up." The list gets written, and then nothing happens to it.

The same team's public SRE workbook explains the cause: action items without clear owners are less likely to be resolved. An item that belongs to "the team" belongs to no one on any given day, because no single person feels the item is theirs to finish. An item with a name next to it has exactly one person who can be asked, tomorrow, whether it is done.

Give every action item one owner instead of a team

Write the owner's name on the line, at the moment the item is created, before the meeting ends. A person, never "backend team" or "someone should look at this."

A blameless postmortem separates two questions that are easy to mix up: what happened, and who makes sure the fix gets done. Naming an owner answers the second question only. The owner is the one person accountable for getting a specific item finished, which might mean writing the fix themselves or making sure the right person does, and nobody is defending a decision they made during an outage by taking that role. PagerDuty's incident response documentation makes the same distinction: ownership is an administrative role that makes sure the item is completed, separate entirely from who was on call when the incident happened.

If you cannot name an owner in the meeting, that is worth noticing rather than working around. It usually means the item is too vague to hand to anyone, or that nobody in the room actually believes it will get built. Either way, insisting on a name shows the problem while the group is still together to fix it, instead of a month later when the item is quietly gone.

Watch for the version of this that looks like ownership but is not. A manager's name on every line is not the same thing as an owner, because a manager assigning twelve items to themselves across three teams cannot actually do the work on any of them, and everyone in the room knows it. The name on the line should belong to whoever will open the pull request, write the alert, or change the config, not whoever is easiest to write down when the meeting is running long.

Give every action item a date, sized to the risk

An item with an owner and no date gets delayed. The item sits at the bottom of someone's list behind whatever came in that morning, and it stays there until the next incident makes it urgent again.

There is no single correct number of days, but a real reference number is useful. PagerDuty's guidance recommends completing high-priority action items tied to a severity-1 incident within 15 days, and items tied to a severity-2 incident within 30 days. Whether your team uses that exact scale or its own, the underlying rule is what matters: the length of the deadline should match how bad it would be if the same failure happened again tomorrow, and every item gets a real date, not "soon."

Google's SRE guidance adds a second useful discipline here: word the item so it is obvious when it is done. Their examples contrast "investigate monitoring for this scenario," which never has a clear end, with "add alerting for all cases where this service returns more than 1 percent errors," which either exists or it does not. A vague item cannot have a real deadline, because nobody agrees on what finishing looks like. Write the item narrowly enough that the date applies to something concrete.

Review the list on a fixed schedule

A single meeting where good intentions get written down is not enough by itself. What separates a team whose reliability improves over time from one that keeps dealing with the same incidents again is whether anyone looks at the list again after the meeting ends.

Put a recurring slot on the calendar, weekly or every two weeks depending on incident volume, where the only agenda item is: what is still open, who owns it, and is the date still realistic. This does not need to be long. It needs to happen on a schedule that does not depend on someone remembering, because relying on memory is exactly the gap that let items disappear in the first place.

Two things belong in that review beyond a status check. First, an item that is genuinely no longer worth doing should be closed, not left open forever making the list longer and making people feel guilty; an open item nobody intends to finish is worse than no item, because it hides the real work among items nobody will do. Second, an item that keeps missing its date is a warning: either the estimate was wrong, or the owner does not have the time this actually needs, and both are worth reporting to whoever can change the priorities, rather than letting the date quietly move again.

What this looks like when we scope a build

When we scope engagements, we treat the postmortem's action item list the same way we treat any other list of planned work. An item with an owner and a date is planned work. An item without either one, no matter how well the surrounding analysis reads, is a note that something should happen someday.

That habit matters more as the pace of change goes up. Teams releasing more code, including AI-generated code reviewed against an eval suite before it is released, tend to also produce more incidents to learn from, simply because more changes are reaching production. That means more postmortems and a longer list of proposed fixes competing for the same hours. A list without owners and dates stops working at that volume. It grows faster than anyone closes it, and the postmortem process turns into paperwork that gets written and never read again.

The short version

A postmortem without an owner on every line is a well-documented reason the same incident will happen again. Name the person, set the date, and put the open list in front of the team on a schedule that does not depend on anyone's memory. Only a postmortem whose list gets finished, one item at a time, has ever changed anything.

Sources

John Lunney, Sue Lueder, and Betsy Beyer, "Postmortem Action Items: Plan the Work and Work the Plan," USENIX ;login:, Spring 2017: Google's SRE team names lack of follow-up as the most common shortcoming in postmortems and sets out the actionable, specific, bounded criteria for writing an action item.
Google SRE Workbook, "Postmortem Culture": states that action items without clear owners are less likely to be resolved and describes assigning both an owner and a tracking number to every item.
PagerDuty, "Accountability," Postmortem Documentation: recommends closing severity-1 action items within 15 days and severity-2 action items within 30 days, and frames ownership as an administrative role separate from blame.

How to write a postmortem that changes behaviour