Post-incident action items: how to make them stick

Post-incident action items die after the retrospective because nobody owns them, nothing makes them due, and they sit in a document instead of the backlog engineers plan from. Five rules fix most of it: one owner per item, a due date, priority tied to incident severity, tracking in the team’s work tracker, and review on a fixed cadence.

This guide covers what happens after the meeting. How to run the retrospective itself, from agenda to facilitation, is in the postmortem meeting guide. Here you get the failure modes, the fields every action item needs, examples of weak and strong items, a follow-through process, a review cadence, the metrics to report, and an audit checklist.

Why action items fail

Action items usually stall because the process around them makes them easy to drop. These are the failure modes that show up again and again.

The owner is a team. “Platform team to investigate” means everyone on the platform team assumes someone else has it. Several people can share the work, but one person has to answer for whether it gets done.
There’s no due date. Without a date, an item never becomes late, so it never comes up in a review. It just ages.
The wording is vague. “Improve monitoring” can’t be finished, because nobody can say what finished looks like. Vague items stay open forever or get closed on a technicality.
The item lives only in the retrospective document. Engineers plan from the tracker. An item that exists only in a document nobody reopens is invisible the day after the meeting.
Priority isn’t tied to risk. Follow-up work competes with roadmap work. If a SEV1 fix and a nice-to-have cleanup carry the same priority, the roadmap wins both times.
The retrospective produces too many items. A list of fifteen items from one incident reads as a wish list. Teams finish the easy three and the important ones stall.
Nobody reviews open items. Without a standing review, overdue items surface only when the same incident happens again.
The scope is too big to start. “Re-architect the queue” needs a design doc, a quarter of work and a budget. As a single action item it never begins.
Items close without verification. The ticket says done, the code merged, and the failure mode is still there. Closing the ticket isn’t the same as removing the risk.

Every rule in the rest of this guide answers one of these.

The fields every action item needs

Before the retrospective ends, check each action item against these fields. If a field is missing, fix it in the room, while the people who can answer are still there.

Field	Why it matters	Weak example	Strong example
Owner	One accountable person makes the item someone’s job. Others can help, but one person reports status.	“Payments team”	“One named engineer on the payments team, with help from the database on-call”
Due date	A date makes the item reviewable and lets it become overdue, which is the signal you need.	“Soon” or “Q3”	“14 days after resolution”
Priority	Priority decides what gets dropped when the sprint is full. Tie it to the incident’s severity.	Everything “medium”	“High: SEV1 contributing factor”
Linked incident	The link keeps context for whoever picks up the ticket and lets you report follow-through per incident.	Ticket with no reference	Ticket links the incident record and the retrospective section it came from
Acceptance criteria	A written done condition stops vague items and premature closure.	“Fix alerting”	“Alert fires within 5 minutes when p95 checkout latency exceeds 2 seconds, routed to the payments rotation, tested in staging”
Ticket link	The tracker is where the work gets scheduled. The link in the incident record shows it exists.	“Will create a ticket”	Jira, Linear or Asana issue key recorded on the action item

Two more fields are worth adding once the basics hold: the type of improvement (prevent, detect, mitigate or communicate) and verification, a short note on how you’ll know the fix worked. The root cause analysis guide covers how to turn contributing factors into fixes you can verify.

Weak vs strong action items

These examples come from common incident patterns. Each weak version is something a tired room writes at the end of a long meeting. The strong version is what it takes to make the item finishable.

Incident scenario	Weak action item	Strong action item
A TLS certificate expired on an internal API and broke service-to-service calls for 40 minutes.	“Don’t let certs expire again.”	“Add expiry monitoring for every certificate in the internal CA, alerting the owning service’s rotation 21 days before expiry. Owner: one named SRE. Due 14 days after resolution. Done when a test certificate with a 20-day expiry pages the right rotation.”
A connection pool ran out under a traffic spike and the API returned errors.	“Look into the connection pool.”	“Set the pool size from load-test results for 2x peak traffic and add a saturation alert at 80%. Done when the load test runs at 2x peak with no pool exhaustion and the alert fires in staging.”
A feature flag rolled out to all users at once and broke sign-in.	“Be more careful with flags.”	“Require staged rollout (1%, 10%, 50%, 100%) for flags on the sign-in path, enforced in the flag tool’s change policy. Done when a direct 100% rollout on a tagged flag is rejected.”
The primary on-call missed the page because the schedule had a gap over a holiday.	“Check the on-call schedule.”	“Add a weekly check that flags any gap in production on-call coverage for the next 30 days and posts it to the team channel. Done when a deliberate one-hour test gap gets flagged.”
A third-party API started rate-limiting and the retry logic made it worse.	“Fix retries.”	“Add exponential backoff with jitter and a circuit breaker to the vendor client, capped at 3 retries. Done when a fault-injection test against a rate-limited stub shows request volume falling, not rising.”
The incident was found by a customer support ticket 25 minutes before any alert fired.	“Improve detection.”	“Add a synthetic check for the order-confirmation flow every minute from two regions, paging on two consecutive failures. Done when a staged failure pages within 3 minutes.”
A database migration locked a busy table during business hours.	“Run migrations at night.”	“Add a CI check that fails migrations taking table-level locks on tables over 1 million rows unless they use the online migration tool. Done when the check blocks a test migration in CI.”

A pattern runs through the strong column. Each item names a mechanism (an alert, a check, a policy, a test) and the evidence that will show it works. Prefer fixes that stop the whole class of failure over a patch for this one instance.

How to run post-incident follow-through

This is the process that turns a list of items into finished, verified work. Steps 1 to 3 happen in the retrospective. The rest happen afterwards, which is where most follow-through breaks.

Draft one candidate item per contributing factor. Work from the contributing factors the review identified, so the list covers what caused the incident. If a factor gets no item, write down why.
Cut the list. Keep the items that reduce real risk. Move ideas that aren’t commitments to a separate “considered” list in the retrospective so they aren’t lost, but don’t track them as action items.
Fill every field before the meeting ends. Owner, due date, priority, acceptance criteria and the linked incident. An item that leaves the room without an owner usually stays without one.
Split big items. If an item needs more than a sprint, create a short-term mitigation with its own due date and a separate roadmap item with an accountable leader. Track both.
Put every item in the tracker within one business day. Create the ticket in the team’s normal backlog, with the incident link, so it shows up in sprint planning like any other work.
Get the owner’s acceptance. The owner confirms the scope and date within two business days, or the item goes back to the retrospective owner for reassignment. Silent assignment is how items go stale.
Review on a fixed cadence. Weekly at team level, monthly at leadership level, with clear escalation rules for overdue items. The next section has a cadence you can copy.
Close with evidence. The owner links the change (a pull request, a config change, a runbook revision) and shows the acceptance criteria are met.
Verify the fix worked. Run the test, drill or check named in the item. For some fixes the only real verification is the next similar event behaving differently, so note what to look for.
Close the loop on the incident. When every high-priority item for an incident is done and verified, mark the follow-up complete in the incident record and share what changed with the people who were affected.

Set a review cadence for open action items

Follow-through depends on someone looking at open items on a schedule. Keep the reviews short and specific so they survive busy weeks.

Review	Who runs it	When	What it covers	Output
Weekly triage	Engineering manager or the team’s reliability lead	Every week, 10 to 15 minutes, in an existing team meeting	New items missing an owner or date, items due in the next 7 days, overdue items	Every item has an owner and a date; overdue items have a new date or an escalation
Monthly reliability review	Engineering director or head of reliability	Once a month, 30 minutes	On-time completion rate by team, oldest overdue items, repeat incidents, items that need roadmap time	Decisions on funding, re-scoping or accepting risk for the items that are stuck
Quarterly look-back	Reliability lead with engineering leadership	Once a quarter	Trends in the metrics below, recurring contributing factors across incidents	Themes for reliability roadmap planning

Escalation rules for overdue items

Overdue by	What happens
Due date reached	Owner gets a reminder.
7 days	Item goes on the weekly triage agenda with the owner’s manager present.
14 days, or any overdue item from a SEV0 or SEV1 incident	Item goes to the monthly reliability review for a decision.
Slipped twice	The item is re-scoped, reassigned, or closed as accepted risk with a named approver and a written reason.

Accepting risk is a legitimate outcome. Some fixes cost more than the risk they remove. Someone with authority should make that call on the record, so the item doesn’t age quietly in the backlog.

Follow-through metrics to report

Report these together. A team can push on-time completion to 100% by writing small, safe items, so pair it with repeat incidents, which shows whether the items mattered.

Metric	Formula	What it tells you
On-time completion rate	Items completed on or before their due date ÷ items due in the period × 100	Whether commitments made in retrospectives are kept. Report it by team and by incident severity.
Median days to close	Median of (completed date − created date) for items completed in the period	How long follow-up work takes. A rising median often means items are too large or not prioritized.
Overdue age	For each open item past its due date: today − due date. Report the count, the median and the oldest.	The size and staleness of the follow-up backlog. The oldest item is usually the most useful number in the room.
Repeat-incident rate	Incidents in the period that share a contributing factor or failure mode with an earlier incident ÷ all incidents in the period × 100	Whether fixes are working. It moves slowly, so watch the three metrics above while you wait for it.
Assignment lag (optional)	Median of (owner assigned date − created date)	Whether items leave the retrospective with an owner or wait for one.

Use a fixed window, such as the last 90 days, so numbers are comparable month to month. Define “repeat” before you start counting, for example the same service and the same contributing factor within 90 days, and keep the definition stable.

Audit-readiness checklist for incident follow-up

Auditors reviewing incident management, for SOC 2 and similar frameworks, often sample incidents and ask for evidence the team learned from them. Completed, linked action items are a large part of that evidence. Audit-ready incident records covers the full record auditors expect. For follow-up specifically, check that:

Every action item links to its incident by a stable ID.
Every item has a named owner, a due date and a priority.
Status changes are timestamped, so you can show when an item was opened, reassigned and closed.
Closed items carry evidence: a pull request, a configuration change, a test result or a drill record.
Items closed without a fix are marked as accepted risk, with the approver and the reason.
The retrospective is published and linked from the incident record.
Overdue items from high-severity incidents show an escalation or a decision.
You can export action items and their history for the audit period in a format the auditor can review outside the tool.

How teams do this in Rootly

Rootly treats action items as part of the incident record, so follow-up work stays connected to the incident it came from. Teams use it to run the process above with less manual chasing.

Capture action items during the incident and the retrospective. Rootly action items come in two types: tasks for work during the incident and follow-ups for work afterwards. Each follow-up carries an assignee, a priority (high, medium or low), a due date, a status and optional custom fields. Responders can create them from Slack with /rootly followup or by reacting to a message with an emoji, and /rootly todo lists the items assigned to you.
Review them in the retrospective. The default retrospective template includes a Follow-Up Actions section rendered from the incident’s action items. Custom templates can insert a live follow-ups block with the /followups command, and a retrospective process can include a step for creating follow-ups that shows each item’s status, due date and assignee.
Sync them to Jira, Linear and Asana. With Jira, Rootly can create a subtask under the incident’s Jira issue for every new action item, keep it updated as the action item changes, and match its priority. Linear gets a sub-issue under the incident issue, and Asana gets a subtask whose completion can mirror the action item’s status. You can also export selected items manually to Jira, Linear, Asana, Trello or Zendesk.
Set due dates from severity and chase overdue work. SLA policies for follow-ups set assignment and completion deadlines automatically, counted in days from an incident status such as Resolved. Conditions let a SEV1 follow-up get a shorter deadline than a SEV3 one. The policy’s manager is notified before the deadline, on the day it falls due and after it passes, and Rootly records a violation when an item is unassigned or incomplete past its deadline.
Automate the rest with workflows. Action item workflows run when an item is created or when its status, assignee, priority or due date changes. They can check incident severity, then create or update tickets or post a Slack or Microsoft Teams message, for example telling the owner when they’re assigned a high-priority follow-up.
See open work across incidents. The web interface lists action items across all incidents, filterable by priority, type and status, and exports them to CSV, JSON or XML for monthly reviews and audits.

The Retrospectives page shows how this fits with the rest of Rootly’s post-incident workflow, and automating action item tracking from retrospectives walks through one setup.

Frequently asked questions

What is the best way to improve post-incident follow-through?

Give every action item one owner, a due date and a priority tied to the incident’s severity, put it in the tracker where engineers plan their work, and review overdue items every week. Close items only when the fix is verified. Rootly syncs follow-ups to Jira, Linear or Asana and sets deadlines from severity with SLA policies.

How do we make sure postmortems lead to real follow-up actions?

End the retrospective with each action item fully specified: owner, due date, priority, acceptance criteria and a link to the incident. Create the tickets within a day, get each owner’s acceptance, and put overdue items on a weekly agenda with clear escalation rules. Report on-time completion monthly so leadership sees whether commitments are kept.

Who should own post-incident action items?

One named person per item, usually an engineer on the team that owns the affected service. Others can do part of the work, but one person is accountable for status. The retrospective owner or incident commander makes sure every item has an owner before the meeting ends.

How long should post-incident action items take to complete?

Set the deadline from severity. A common starting point is 14 days for high-priority items from SEV0 and SEV1 incidents and 30 days for the rest. Work that needs more than a sprint should be split into a short-term mitigation with its own deadline and a roadmap item with an accountable leader.

How many action items should a retrospective produce?

Only as many as the team will finish. One item per significant contributing factor is a good guide. Keep ideas that aren’t commitments in a “considered” list in the retrospective and out of the tracker, so the tracked list stays credible.

What should happen to action items that keep slipping?

After a second missed date, make a decision: re-scope the item, reassign it, or close it as accepted risk with a named approver and a written reason. Accepting risk is a valid outcome when the fix costs more than the risk it removes, as long as someone with authority decides on the record.

How do you measure whether action items are working?

Track on-time completion rate, median days to close, overdue age and repeat-incident rate together. Completion shows whether commitments are kept. Repeat incidents show whether the fixes mattered. A team with high completion and a rising repeat rate is writing items that are too small or aimed at the wrong causes.

Should action items live in the retrospective document or in a ticketing tool?

Both, linked. The retrospective explains why each item exists, and the ticket in Jira, Linear or Asana is where the work gets scheduled. In Rootly the action item on the incident is the source, and workflows keep the external ticket in step with it.