🔎 RCA Methods: 5 Whys vs Causal Chains vs Contributing Factors

Root-cause analysis is where postmortems go wrong most often, because the method you choose shapes the answer you get. Pick a linear method for a multi-causal incident and it will hand you one tidy cause and quietly discard the rest. This guide covers the three approaches you’ll actually use — 5 Whys, causal chains, and contributing-factor analysis — with a rule of thumb for when each fits.

Method 1: 5 Whys

You know this one. Start with the failure and ask “why?” repeatedly, each answer becoming the next question, until you reach something fundamental.

The checkout API returned errors. Why? The database rejected connections. Why? The connection pool was exhausted. Why? A slow query held connections open. Why? A new report query had no index. Why? There’s no review step that catches missing indexes before merge.

Strengths: Fast, teachable, needs no tooling, and produces a satisfying single answer that maps neatly to one action item.

Weaknesses: It’s linear. It assumes a single chain when real incidents usually have several conditions lining up at once. And it has a notorious failure mode — it tends to stop at the first answer that sounds like a person (“the engineer pushed a bad config”), which feels like a root cause but is really where the interesting questions begin.

Use it when: The incident is genuinely simple and single-threaded — one clear trigger, one clear chain. Most small incidents qualify.

Method 2: Causal chains (and graphs)

When an incident has more than one thread, a single ladder of whys can’t represent it. A causal graph does: you map each condition as a node and draw arrows for “contributed to.” Instead of one chain you get a web, and the outage sits at the point where multiple chains converge.

Take a real-feeling example: an outage happened because (a) a deploy introduced a slow query, and (b) the connection pool was sized too small for years, and (c) the alert on pool saturation had been muted during an unrelated noisy period and never re-enabled. Remove any one of those and there’s no outage. A 5 Whys walks down exactly one of those branches and calls it “the” cause. A causal graph shows all three, which is the truth.

Strengths: Represents multi-causal reality. Surfaces latent conditions (the years-old pool sizing) that linear methods skip. Makes it obvious you have several independent things to fix.

Weaknesses: Slower, needs a facilitator to keep it honest, and can sprawl if you don’t bound it. It’s overkill for a small, obvious incident.

Use it when: The incident is severe, surprising, or crossed multiple teams — anywhere “what was the root cause?” gets three different answers from three responders.

Method 3: Contributing-factor analysis

The third approach drops the word “root” entirely. Instead of hunting for the cause, you enumerate every factor that made the incident more likely or more severe, then decide which are worth acting on. It’s less a diagram and more a disciplined list.

A contributing-factors write-up might read:

• Trigger: deploy of a query with no index.
• Contributing: connection pool undersized; saturation alert muted; runbook for pool exhaustion out of date; on-call unfamiliar with this service.
• Aggravating: incident started during a shift handover.

The value is that it refuses to collapse a messy reality into one culprit, and it naturally produces a spread of action items across prevention, detection, and mitigation.

Strengths: Honest about complexity, resists blame (a list of factors doesn’t point at a person), and directly seeds diverse action items.

Weaknesses: Can become an undifferentiated pile if you don’t rank factors by how much they mattered and how cheap they are to fix.

Use it when: You want breadth over a single narrative — especially for incidents where “why did this become an outage?” matters more than “what was the trigger?”

Choosing: a quick decision guide

Signal	Reach for
Small, single-threaded incident	5 Whys
Multiple responders give different “root causes”	Causal chain/graph
Latent conditions suspected (old config, tech debt)	Causal graph
You want a spread of prevent/detect/mitigate fixes	Contributing factors
Cross-team incident with tangled ownership	Contributing factors + graph

You don’t have to pick one and marry it. A common pattern: run a fast 5 Whys to get the obvious chain, then ask “what else had to be true for this to become an outage?” and switch to contributing factors to catch the rest.

The trap all three methods share

Every method fails the same way if the facilitator lets it: stopping at human error. “The engineer made a mistake” is never a root cause — it’s a prompt. Why was a mistake that easy to make? Why did the system have no guardrail? Why did it reach production undetected? A blameless RCA treats a human action as a symptom of a system that permitted it, and keeps going.

The second shared trap is stopping at something you can’t change. If your analysis bottoms out at “the vendor’s API is unreliable,” that’s real, but the actionable finding is one level up: “we have no timeout or fallback when that vendor is slow.” Chase why until you hit something you own, then stop.

Wrapping up

5 Whys is the right tool for simple incidents and the wrong tool for complex ones. Causal graphs handle the multi-causal reality that linear methods erase. Contributing-factor analysis gives you breadth and naturally resists blame. Match the method to the incident, refuse to stop at “human error,” and keep asking why until you reach something you can actually change.

Related

• Five-Whys vs Causal Graphs: When Each Postmortem Method Fits
• Postmortem Anti-Pattern: The Single Root Cause Fallacy
• How to Write a Blameless Postmortem That People Actually Read