Root Cause Analysis: The 5 Whys and Fishbone with Examples

Fixing the symptom feels good and usually brings the problem back. Root cause analysis asks a more useful question: what would have to change so this type of problem does not happen again?

What root cause analysis is, and why it matters

Root cause analysis (RCA) is a family of methods for working backwards from a problem to the underlying conditions that made it possible. A developer restarts a crashing service and moves on; an engineer who does RCA finds out why it crashed and fixes that. Support teams use RCA on repeated complaints, analysts use it on unexpected metric changes, and engineering teams use it after outages.

It matters because repeating the same incident is expensive and demoralising, and because showing you can look beneath a problem is a strong signal in both interviews and day-to-day work.

The 5 Whys

The 5 Whys technique is associated with Sakichi Toyoda and was developed and used within Toyota's production system, where Taiichi Ohno made it widely known. The idea is simple: state the problem, ask why it happened, then ask why about that answer, and repeat until you reach a cause you can act on. Five is a rule of thumb, not a magic number. Sometimes three questions are enough; sometimes you need seven.

Worked example: a checkout outage

Scenario: an e-commerce site's checkout returned errors for about 40 minutes on a Saturday. Here is how a team might run the analysis. The facts at each level come from logs and timelines, not guesses.

Problem: Between 14:05 and 14:45 on Saturday, about 1 in 3 checkout attempts failed with a 500 error.

Why 1: Why did checkouts fail?
Because the payment service timed out waiting for the database.
(Evidence: timeout errors in payment service logs from 14:05.)

Why 2: Why did the database respond slowly?
Because all database connections were in use, and new requests queued.
(Evidence: connection pool at its maximum of 50 from 14:03.)

Why 3: Why were all connections in use?
Because a new reporting query, deployed at 13:55, held connections open for several seconds each.
(Evidence: slow query log shows the report query from 13:56.)

Why 4: Why did a reporting query run against the production checkout database?
Because the reporting job was pointed at the primary database; no read replica was configured for it.
(Evidence: job configuration in the deploy commit.)

Why 5: Why was it deployed without anyone noticing the connection use?
Because our deployment checklist has no step for reviewing database load impact, and there is no alert on pool saturation.

Root causes / actions:
- Point reporting jobs at the replica. Owner: Dev. Due: Wednesday.
- Add alert when connection pool is above 80% for 2 minutes. Owner: Meera. Due: Friday.
- Add database impact line to the deployment checklist. Owner: Karan. Due: next Monday.

Notice the difference in answers. 'Because the database was slow' is a description. 'Because the checklist has no step for database load and no alert exists' is something a team can change. The first stops the same query; the last two prevent a whole class of similar incidents.

Fishbone (Ishikawa) diagrams

When a problem might have several unrelated causes, a single chain of whys can miss them. The fishbone diagram, also called an Ishikawa diagram after Kaoru Ishikawa, lays out possible causes under categories, like bones branching from a fish's spine toward the problem at the head. It is a brainstorming tool: it lists candidates; you still need evidence to confirm which ones apply. Classic categories come from manufacturing, and teams adapt them to their own work.

You can then pick the two or three most likely branches, gather data, and run 5 Whys on each. The two tools work well together: fishbone to widen your view, 5 Whys to go deep.

The limits of 5 Whys

• It follows one path, so it can miss other contributing causes. Complex incidents usually have several.
• Results depend on who is asking. Two people can run the same analysis and stop at different places.
• It can stop at a person ('the engineer forgot') instead of a system. If your last 'why' is a person's mistake, ask why the system allowed that mistake to cause harm.
• It relies on knowledge you may not have. If nobody knows the answer, the method gives you a gap to investigate, not a conclusion.
• Real incidents may involve interacting factors where no single cause is the root. More detailed methods for complex systems exist, and you should reach for them for serious or safety-related incidents.

Blameless framing

A blameless review assumes that people acted sensibly given what they knew at the time, and asks what about the system made the bad outcome possible. This is not about avoiding accountability; it is about getting honest information. If people expect punishment, they hide mistakes, and you lose the evidence you need.

Blame wording: "Karan deployed a bad query without checking."
System wording: "The deployment process allowed a query that holds connections to reach production without a load review or an alert."

Questions that keep a review blameless:
"What did we know at the time?"
"What made this the reasonable thing to do?"
"What would have caught it earlier?"
"What can we change so that the next person can't hit this?"

Common mistakes

• Stopping at the first plausible answer because it is easy to fix.
• Answering with opinions instead of evidence from logs, data or timelines.
• Ending at 'human error'. That is almost always a symptom of a missing guardrail.
• Producing actions with no owner or date, so nothing changes.
• Using the exercise to find someone to blame.
• Treating five as a rule and stopping at exactly five, or forcing a single root cause when there are several.

How this shows up in interviews and on the job

In behavioral interviews, 'Tell me about a time something went wrong' is an invitation to show RCA: how you found the cause, what you changed, and how you know it helped. Use the STAR method and keep the tone blameless, even about your own mistakes. See also How to Answer 'What Are Your Weaknesses?' for how to talk about your own errors constructively. In system design and engineering interviews, thinking about failure modes is the same muscle, as covered in the System Design Interview Prep Guide. On the job, a short written RCA after any significant problem is a habit that quickly gets noticed.

How to practice

Take a recent small failure of your own, such as a missed deadline, a bug you introduced or a wrong number in a report, and run a 5 Whys with evidence for each step. End with one change to a process or checklist, not 'be more careful'.