What Is Root Cause Analysis?

Last verified on Nov 8, 2026.

Root cause analysis (RCA) is a structured way to work out why a failure happened, so that the fix removes the underlying condition and not only the symptom. In software it usually runs after an incident, alongside a postmortem, and it ends in actions that make a repeat less likely.

AHRQ describes RCA as a method that looks for the underlying problems that make errors likely, while avoiding the trap of blaming individuals. It separates active errors, which happen at the point of contact with the system, from latent errors, the hidden weaknesses that let those errors do harm.

Root Cause, Trigger, and Contributing Factors

Three terms get mixed up, so keep them apart:

• Trigger: the event that set the failure off, for example a deploy or a traffic spike.
• Root cause: the condition that turned the trigger into an outage, for example a latent bug or a missing safeguard.
• Contributing factors: everything else that made it worse or slowed recovery, such as a noisy alert that got ignored.

Google's example postmortem lists Root Causes and Trigger as separate fields. AWS guidance asks you to identify contributing factors, not a single culprit, and to ask why existing testing did not find the issue.

The 5 Whys Method

Ask why the problem happened, then ask why about the answer, and repeat. AWS lists the five whys among the techniques for post-incident analysis, and the CMS worksheet spells out the method. It adds a useful test: if the latest answer were corrected, would the problem still be likely to recur? If yes, it is a contributing factor, so keep going. It often takes three to five whys, and sometimes more. CMS also notes the method does not always find the root cause and suggests a fishbone diagram as another technique, because it forces you to think across categories.

This is a made-up example:

Problem: Checkout returned HTTP 500 for 22 minutes after a release.
Why 1: The checkout pods were restarting with out-of-memory errors.
Why 2: The new version loads the full price catalog into memory at startup.
Why 3: The change was reviewed for correctness, and nobody checked memory use.
Why 4: Staging holds about 1% of production data, so the load never showed.
Why 5: The release process has no step that exposes a change to real traffic first.

Fixing the pods would have ended the outage. Fixing the last two answers, with production-sized test data and a canary deployment, changes what happens next time.

A Practical Sequence

1. State the problem in one sentence, with the user-visible effect and the time window.
2. Build the timeline from logs, deploy events, and alerts. Order events by timestamp and mark which ones you know and which you are inferring.
3. List hypotheses and test each against data. A query that disproves a theory is progress. Google's troubleshooting chapter covers this loop.
4. Ask why until the actions are about systems. "Engineer forgot" is not a stopping point. AWS names stopping at human error as an anti-pattern.
5. Write actions with owners. Prefer a change to an automated check over a reminder to be careful.

Tracing a request across services shortens step 2. Distributed tracing shows which hop failed, and the deploy that preceded the first error is the usual first hypothesis, which is the subject of regression detection.

Common Mistakes

• Stopping at the trigger because it is easy to name.
• Treating "root cause" as one item when the evidence shows several. The CMS worksheet has room for more than one.
• Accepting a cause you cannot test against the logs.
• Writing the analysis only for the team involved. Google's review criteria ask whether the root cause was sufficiently deep and whether the outcome was shared with stakeholders.

Root Cause Analysis in Sazabi

Sazabi, an AI-native observability and security platform, opens an issue that arrives already investigated, with the agent's analysis of what happened and why. You can copy the issue's agent prompt into your own coding agent, which continues the investigation in your repository. The fix is written and reviewed in your own workflow. Related reading: MTTR and the novel events detection guide.