Software & TechnicalFree
Postmortem Action Item Follow-Through Review
River matches every action item your postmortems wrote against the ticket system, then names the incidents that repeated while that work sat open.
River reads your postmortems and your ticket export as two versions of one list that are supposed to agree. Every action item a postmortem wrote is matched to a real ticket or marked as never filed. Then each incident is checked against the actions written after earlier incidents, so a repeat that an unfinished item would have prevented is named as one. The count of actions that never reached the tracker comes back first, because no dashboard the team already has can produce it.
Search this question and you get advice. Assign an owner, set a due date, review them weekly. All true, none of it counted. Cranmore, a logistics software company, wrote 34 postmortems and 211 action items across eighteen months. Its tracker reported 48% closed, because a tracker can only report on the 128 items that reached it. Against what the postmortems actually wrote the rate was 29%, and 83 items had never been filed.
Built for the reliability lead arguing for remediation time against a feature roadmap, and for the engineering manager with a quarterly review to prepare. Run it before that meeting rather than after the next repeat, since the argument reads very differently when it arrives in advance. It picks up where the incident postmortem writer left off, and hands the still-open detection items to the monitoring coverage review. Eighteen months is a good window; six rarely contains a repeat.
The rate is measured against the wrong list
A tracker can only report on tickets, so a completion rate pulled out of Jira is computed over the items that became tickets. That is not the list the postmortems wrote. PagerDuty's postmortem template requires every action item to be a Jira ticket carrying two tags, one naming the severity and date of the incident and one naming the severity alone. The requirement exists because without it the item and the incident are two records nothing joins.
When failures start to mirror each other, Google's SRE workbook says to dig deeper and asks first whether action items are taking too long to close. Its second question is whether feature velocity is beating reliability fixes, which is the trade an error budget policy exists to settle. Answering either one means reading every postmortem in the window at once and joining all of them to the tracker. Filed individually, one document per incident, the pattern is visible from none of them.
Sorting by type is where the asymmetry shows up. At Cranmore the process items closed at 42% and the preventive ones at 13%, so the paperwork finished and the work that stops recurrence did not. AWS puts tracking and delivering every action inside its post-incident analysis practice and rates the risk of skipping that practice as high. The preventive rate is the one nobody reports, and it is the only one that predicts whether the same page fires again.
How it works
Send the postmortems
Every postmortem in the window, plus the incident list, including the incidents nobody wrote one for.
Add the tracker
The ticket export for the same period, with created dates, closed dates and current status.
Pick the repeat rule
Decide what counts as the same failure twice, because the repeat count moves with that choice.
Take the argument
The traced repeats, the hours they cost, and the estimate on the work that would stop them.
What you get
- Every action item your postmortems wrote, matched to a ticket or marked never filed
- Two completion rates side by side, the tracker's and the one your postmortems support
- Closure split by prevent, detect, mitigate and process, which is where it collapses
- Each open item aged from its incident rather than from the day somebody filed it
- The repeat incidents traced back to an action item that was written and never done
- Responder hours on those repeats set against the estimate on the work that stops them
Common questions
Our action items are all in Jira already.
Then the tracker half is easy and the other half is the finding. The run still reads the postmortem documents and matches item by item, because the items that never became tickets are the ones no query can return. At Cranmore that set was 83 of 211, and six of the nine items behind its repeat incidents were in it.
How does it decide two incidents are the same?
You pick the rule on the form, because the count moves with it. Same service and same failure mode is the strictest. Same underlying cause across different services catches a shared dependency. The loosest is whatever the on-call would recognise as the same page. Choose the last option and every repeat is labelled with the rule it met.
Is this a report on how bad we are?
It is the opposite argument, and it is priced. Cranmore's 13 traced repeats consumed 460 responder hours, while the nine action items behind them carried estimates totalling 23 engineering days. That comparison is what moves reliability work up a roadmap, and making it needs both halves of the join to exist.
We do not write a postmortem for everything.
That gap is part of the output. Cranmore had 47 incidents at Sev-2 or worse and 34 postmortems, so 13 serious failures left no document and no action items behind them. Paste the incident list anyway. Where one of those turns out to be a repeat, the timeline reconstruction can build the record after the fact.
Why age an item from the incident instead of the ticket?
Because a ticket opened two months after the outage is already two months old on its first day, and the tracker's age field starts at zero anyway. Cranmore's median open item was 210 days old by its ticket and 270 days old by its incident. Six were past a year on the first clock and twelve on the second.
What about items that are no longer worth doing?
Those get a status of their own rather than being counted quietly as failures. An item can be obsolete because the service was retired, superseded by a larger piece of work, or simply wrong when it was written. Each of those needs a decision and a name against it. What it must not do is sit open for a year without one.
What comes out of it?
A sheet with one row per action item, carrying its postmortem, its type, its ticket or the absence of one, and its age on both clocks. Then a document naming the repeats and what they cost. Mitigation items that are still open usually belong in the runbook until they are done.
Postmortem Action Item Follow-Through Review
Fill in the form and your workspace opens with the work already underway.