What Is Root Cause Analysis? (5 Whys + Fishbone Explained)

Every incident has at least two candidate explanations: the thing that broke, and the reason it was able to break. RCA is the discipline of not confusing the two. ASQ defines root cause analysis as a structured, step-by-step approach used to identify and correct the source of a problem, rather than continuing to treat its symptoms one occurrence at a time. A symptom fix — restarting a crashed process, manually re-running a failed job, refunding an angry customer — makes today's instance of the problem go away. A root cause fix changes something upstream so that class of problem stops happening at all.

That distinction is what separates firefighting from engineering. Teams that only ever fix symptoms end up re-fighting the same fire every few weeks under a slightly different name. RCA exists to break that cycle by forcing the question one level deeper each time: not 'what broke,' but 'what allowed this to break, and would fixing that prevent the next ten instances of it too.'

The best-known RCA technique is the 5 Whys, an iterative method that originated at Toyota as part of its production system. The mechanics are almost embarrassingly simple: state the problem, ask why it happened, take that answer and ask why it happened, and keep going. The '5' is a convention, not a rule — some chains resolve in three whys, others need seven — but five is usually enough to walk past the obvious symptom and land on something structural: a missing process, a false assumption baked into the code, or an absent safeguard.

Here is what that chain looks like on a real software incident, where each answer becomes the next question:

Notice what happened across those five steps. The symptom ('checkout failed') and the proximate technical cause ('the API timed out') are both true, but neither one is fixable in a way that prevents recurrence — the payment provider will be slow again someday, on some other endpoint. The actual root cause, a missing checklist item in code review, is something a team can fix once and have it apply to every future third-party integration, not just this one checkout path.

5 Whys assumes the problem has one linear chain worth following. Plenty of real incidents don't cooperate — an outage might be partly a code defect, partly a monitoring gap, partly a rushed deploy process, and partly an environment difference between staging and production, all at once. For that shape of problem, the Ishikawa diagram, better known as the fishbone diagram, is the complementary technique.

A fishbone diagram puts the problem at the head of the 'fish' and draws a spine with several angled bones branching off it, one per cause category. In software incidents the categories are commonly some variant of People (skills, staffing, on-call load), Process (review steps, deploy gates, runbooks), Technology/Tools (the code, the frameworks, the monitoring stack), and Environment (infrastructure, configuration, third-party dependencies). Under each bone the team lists every plausible contributing factor in that category, without filtering yet — the point of the exercise is breadth, not depth. Only after every branch is populated does the team look across all of them for the factors that actually mattered, which are often a combination rather than a single smoking gun.

Pick the technique based on the shape of the problem, not personal preference. Reach for 5 Whys when you're debugging one specific incident that looks like a single chain — a particular request failed, a particular deploy broke a particular feature — and you just need to follow the thread from symptom to system. Reach for a fishbone diagram when you're stepping back from a single event to ask what a whole class of incidents has in common, or when a team suspects the causes are tangled across categories rather than sequential. That is exactly the situation a blameless postmortem is designed for: several people in a room, each holding a piece of the picture, mapping contributing factors before deciding which ones are worth fixing first. Many teams run both in sequence — fishbone to survey the field, then 5 Whys down the branch that turns out to matter most.

Google's SRE postmortem culture chapter makes blamelessness a first-class principle precisely because of this failure mode: a postmortem that ends at 'human error' has stopped one level too early. The useful question isn't who made the mistake — it's why the process, tooling, or review step didn't catch it before it shipped. Did the code review checklist not require a test for that path? Did the deploy pipeline lack a canary stage that would have caught it at 1% of traffic instead of 100%? Did the alert exist but get buried under noise? Root cause analysis that blames a person instead of a system produces a fix that depends on that same person, or the next one, being more careful — which is not a fix, it's a hope. And hope-based fixes are exactly the ones that recur.

Every step of RCA, whether it's a 5 Whys chain or a fishbone brainstorm, is only as good as the facts feeding it. Step one of the Five Whys — 'why did checkout fail?' — is speculation unless someone can actually answer it with evidence instead of a guess. Was it really a timeout, or was it a validation error that looked like a timeout in the logs? Did the user really hit the payment API at all, or did the request fail before it got that far? Teams without hard evidence tend to answer the first 'why' with whatever theory sounds most plausible, and an RCA chain built on a wrong first answer produces a confident, well-reasoned, completely wrong root cause.

This is where BugMojo fits into the RCA workflow rather than replacing it. A bug report captured through the browser extension carries an rrweb session replay of exactly what the user did, the console log from that session, and the network request and response that actually went out. That turns 'why did checkout fail' from a guess into a lookup: the replay shows the click, the network tab shows the 504 from the payment endpoint, the console shows no retry was ever attempted. Every subsequent 'why' in the chain builds on a fact instead of a hunch, and when the report is handed to an AI coding agent over MCP, the agent can trace the chain against the actual codebase instead of asking the team to reconstruct it from memory a day after the incident.