Tracking and Verifying Post-mortem Action Items
Turn post-mortem findings into concrete, owned, and verified action items so the same incident never recurs, and learn to measure whether remediation actually works.
Tracking and Verifying Post-mortem Action Items is a free Production Debugging & Incident Response Playbook lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Production Debugging & Incident Response Playbook learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why Action Items Matter
A blameless post-mortem that produces no durable change is just storytelling. The real value is in the action items that prevent recurrence.
This lesson covers how to write, assign, track, and verify them.
Anatomy of a Good Action Item
A strong action item is specific and verifiable. Vague items like 'be more careful' never get done.
- Owner: a single named person
- Outcome: an observable change
- Due date: a realistic deadline
- Tracking link: a ticket
Bad: 'Improve monitoring'
Good: 'Add alert on checkout p99 > 2s, owner: Lena, due: 2 weeks, JIRA-4821'Prevent vs Mitigate vs Detect
Classify each action by how it reduces future risk:
- Prevent: stop the cause entirely
- Mitigate: reduce blast radius if it happens again
- Detect: catch it faster next time
A healthy post-mortem usually produces all three categories.
Avoid the Single-Fix Trap
It is tempting to record only the obvious code fix. But incidents have layers. Use the contributing factors from your timeline to generate items addressing process and detection gaps too.
One root cause often yields several action items across these layers.
Prioritizing Action Items
You cannot do everything at once. Score items by impact and effort.
- High impact, low effort: do first
- High impact, high effort: schedule deliberately
- Low impact: question whether to keep
priority = impact_score / effort_scoreAssigning Real Owners
An item owned by 'the team' is owned by no one. Assign a single accountable individual, even if they delegate the work.
The owner is responsible for status, not necessarily for typing the code.
Tracking in Your Issue System
Create action items as tickets linked to the incident, with a consistent label so they are queryable.
This lets you report on completion rate across all post-mortems, not just one.
label: postmortem-action
link: INC-2025-014Measuring Completion Rate
A team that closes 90% of action items within deadline is learning. A team sitting at 30% is repeating incidents.
Track completion as a leading indicator of reliability culture and review it in operational meetings.
completion_rate = closed_on_time / total_action_itemsVerifying the Fix Works
Closing a ticket is not proof. Verify the remediation with evidence:
- A new alert that actually fired in a test
- A chaos experiment reproducing the old failure safely
- A regression test added to CI
Closing the Loop
When verification succeeds, update the original post-mortem with the outcome. This builds an institutional memory: future readers see not just what happened, but what was done and that it worked.
A Lightweight Tracking Workflow
Putting it together:
- Derive items from contributing factors
- Classify prevent/mitigate/detect
- Assign one owner and a due date each
- File linked tickets with a shared label
- Review completion rate regularly and verify before closing
Quick Check
Test your understanding of action item tracking.
Recap
You learned to convert post-mortem findings into durable change.
- Write specific, owned, dated action items
- Cover prevent, mitigate, and detect
- Track in tickets and measure completion rate
- Verify fixes with evidence before closing
Frequently asked questions
Is the “Tracking and Verifying Post-mortem Action Items” lesson free?
Yes — the full text of “Tracking and Verifying Post-mortem Action Items” is free to read here on the web, and the Production Debugging & Incident Response Playbook course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Production Debugging & Incident Response Playbook course, upgrade to CoddyKit PRO.
What will I learn in “Tracking and Verifying Post-mortem Action Items”?
Turn post-mortem findings into concrete, owned, and verified action items so the same incident never recurs, and learn to measure whether remediation actually works. You practise Production Debugging & Incident Response Playbook with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Production Debugging & Incident Response Playbook?
No prior experience is required. Production Debugging & Incident Response Playbook on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Tracking and Verifying Post-mortem Action Items” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Production Debugging & Incident Response Playbook lesson?
Yes. Every Production Debugging & Incident Response Playbook lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Effective Incident Communication Strategies
- Conducting Blameless Post-mortems
- Writing Comprehensive Post-mortem Reports
- Tracking and Verifying Post-mortem Action Items