What is Root Cause Analysis (RCA)?

#How root cause analysis works

The classic technique is repeated questioning: ask why the symptom occurred, then why that condition existed, continuing until you reach something worth changing. A service returned errors because it exhausted its connection pool, because a downstream call had no timeout, because the client library defaults to none and nobody overrode it.

Each answer needs evidence. An RCA built on plausible reasoning without supporting data produces a confident narrative that may be wrong, and the team then fixes something that was not the problem.

#Why root cause analysis matters

Without it, remediation addresses symptoms and the failure returns in a different form.

• Durable fixes: changes at the source prevent recurrence rather than delaying it.
• Class level insight: one root cause often explains several past incidents.
• Prioritization: knowing the real cause tells you what is worth investing in.
• Detection gaps: understanding the chain shows where monitoring should have caught it earlier.

#Limits of the root cause model

The phrase implies a single cause, and complex systems rarely cooperate. Most significant incidents require several conditions to coincide: a latent bug, an unusual traffic pattern, a monitoring gap, and a safeguard that was disabled months earlier. Stopping at the first satisfying answer leaves the others in place.

Investigations also tend to stop at human error, which is where analysis should begin rather than end. If one person's mistake could produce an outage, the meaningful finding is the absence of a safeguard, not the mistake.

#Root cause analysis vs contributing factor analysis

Root cause analysis seeks the origin: the one thing that, changed, would have prevented the incident. It is a clean model that fits simple mechanical failures well.

Contributing factor analysis accepts that several conditions combined, and asks which of them are worth changing. It fits distributed systems better, where incidents emerge from interactions rather than from a single broken part. The practical difference is what you fix. Root cause thinking produces one action item, contributing factor thinking produces several, and in complex systems the second usually reflects reality more accurately.

#Key takeaways

• RCA traces from symptom back to changeable conditions, with evidence required at each step.
• Most significant incidents have several contributing factors rather than one root cause.
• Stopping at human error is a sign the analysis ended early, since the real finding is the missing safeguard.
• Contributing factor analysis fits distributed systems better and produces a fuller set of fixes.

#Frequently asked

How deep should an RCA go?

Until you reach something the team can actually change and that would have prevented the incident. Going deeper into organizational abstraction stops producing actionable findings.

What if no root cause is found?

Document what was ruled out and what remains uncertain. An honest inconclusive RCA is more useful than a fabricated cause that leads to the wrong fix.

Should RCA name individuals?

Only as part of the factual timeline. Analysis focuses on why the system allowed the action to have that consequence.