21 / 51 · 24 Technical Writing for QA · Root Cause Analysis← prev⊞ allnext →☰ Read as one page
3.5Tracking Corrective Actions to Completion
The most common failure in the RCA process is not the analysis -- it is the follow-through. Teams write thorough RCA reports with excellent corrective actions, and then those actions sit in a spreadsheet until the next incident.
Tracking System
- Create tickets for every corrective action in the same system where you track development work (Jira, Linear, GitHub Issues). If it is not in the backlog, it will not get done.
- Assign an owner and a due date. "The team will fix this" means nobody will fix this.
- Review progress weekly in standup or a dedicated 15-minute meeting.
- Close the RCA only when all actions are complete (or explicitly deprioritized with documented rationale).
Corrective Action Categories
| Category | Description | Example |
|---|---|---|
| Immediate fix | Fixes the specific issue that caused this incident | Add the missing database index |
| Detection improvement | Makes similar issues visible earlier | Add migration failure alerting |
| Prevention | Changes the system so this class of issue cannot occur | Add query performance tests to CI |
| Process change | Updates a procedure to prevent recurrence | Add mandatory slow query review for new queries |
| Documentation | Captures knowledge for future reference | Document connection pool limits and circuit breaker config |