When an incident is resolved, the work isn’t over. To truly improve, your team needs to understand why it happened and make sure it doesn’t happen again. That’s what Root Cause Analysis (RCA)—sometimes called a postmortem—is for.
An RCA turns an outage into a learning opportunity. Instead of just moving on, we pause to analyze the timeline, identify causes, and define action items that prevent recurrence. Done well, RCAs are one of the most powerful tools for raising reliability across your systems.
For detailed facilitation tips, see RCA Best Practices
🔗 How RCAs Fit Into Incident Management
The RCA is directly tied to an Incident. Once the Incident is marked Resolved, Phoenix Incidents automatically creates a linked RCA in Jira. Think of it as the second half of the lifecycle:
Incident = firefight and restore service.
RCA = understand and prevent it from happening again.
Just as Incidents have statuses (New → Assessing → Fixing → Resolved → Pending Mitigation → Closed), RCAs have their own workflow:
Data Gathering – collect evidence, logs, timelines, impact summaries.
Analysis Meeting – review what happened, drill down with Five Whys, and identify mitigating actions.
Finalized – RCA is documented, signed off, and action items are being tracked.
🧩 Anatomy of an RCA
Each RCA has a structured format in Phoenix Incidents to make sure no critical step is skipped:
Timeline – key events from the incident start through resolution.
Impact Summary – how customers were affected.
Five Whys – digging into causes, not just symptoms.
Root Causes – categorized, systemic issues that cut across incidents.
Action Items – mitigation work created in Jira, tracked against SLAs.
⏱️ SLA Expectations
RCAs aren’t open-ended—Phoenix Incidents enforces SLAs to keep teams accountable:
RCA Analysis Meeting SLA – your org configures how quickly an RCA must progress from Data Gathering to Analysis Meeting. This ensures incidents are reviewed while the context is still fresh.
Action Item Completion SLA – each action item inherits a due date based on the severity of the original incident. For example, SEV1 action items may be required within 30 days, SEV2 within 60 days, etc. These values are configurable in Phoenix Incidents.
Both of these SLAs are visible in Jira and tracked until complete. If deadlines are missed, they’ll show up in reporting so leaders have visibility.
🎯 Why RCAs Matter
RCAs aren’t just paperwork. They:
Ensure accountability to fix the root cause, not just the immediate issue.
Build a culture of learning rather than blame.
Generate systemic improvements that make your org more resilient.
Provide leadership with visibility into reliability gaps.
Skipping RCAs means the same incidents are likely to repeat, wasting time and eroding trust. Doing them consistently turns painful outages into long-term reliability wins.
Want to run better RCAs? See RCA Best Practices