Five Whys, and Its Limits
One investigative technique for pushing past the first plausible answer — useful, widely over-applied, and structurally unable to represent multiple interacting causes.
The question, the obvious approach, and why it breaks
Every lesson starts where the work starts: an operational problem, a first attempt that is entirely reasonable, and the way production disagrees with it.
When does asking "why" five times help, and when does its single-chain shape misrepresent what actually happened?
Analysis stops at the first answer that sounds sufficient. Five whys exists to push past that. It is then adopted as *the* postmortem method, and its shape — one chain, one terminus — quietly becomes a claim about how failure works.
Take the incident, ask why it happened, ask why that happened, five times, and you arrive at the root cause. Fix that and you are done.
Each "why" has several true answers. The chain follows whichever one the person holding the pen finds most salient, so the terminus is a fact about the room rather than about the system.
- Each "why" has several true answers. The chain follows whichever one the person holding the pen finds most salient, so the terminus is a fact about the room rather than about the system.
- Run the exercise twice with different people and you get different chains from the same incident. That is not a facilitation problem; it is the technique reporting a single path through a branching structure.
- Five is arbitrary. Stopping there is stopping at a number, and the number tends to land wherever "human error" or "the vendor" appears, because both look like terminal nodes.
- A chain has no way to express "these four conditions held simultaneously". It flattens conjunction into sequence and loses the conjunction (Root Cause vs Contributing Factors).
- The single terminus produces a single action item, which is how a five-condition incident gets one fix and recurs.
What is actually happening
Underneath the tooling, which is the part that survives a change of tool.
- The technique comes from manufacturing process improvement, where it works well: a physical production line is largely linear, the failure is usually reproducible on demand, and there genuinely is a step where the wrong thing entered the process.
- Distributed software systems break both assumptions. They have redundancy, so a single failure is usually absorbed and only combinations surface. And they are not reproducible on demand — the state that produced the failure included traffic, timing and the versions running at that instant (Apply Is Not Running).
- What survives the transfer is the *impulse*: refusing the first answer. "The service ran out of memory" is a symptom stated as a cause, and one more "why" reliably converts it into something actionable.
- What does not survive is the *shape*. The honest structure of a software incident is a set of conditions, not a chain, and any technique that only produces chains will produce a chain whether or not one exists.
- Used correctly, the chain is one traversal of a causal graph. That framing keeps the value — depth on one branch — without the claim that the branch is the whole story.
The same incident, chained and branched
Here is a five-whys chain for the checkout incident. Every step is true. Read it and note what is missing: no mention of the alert threshold, the absent canary window, or the missing per-provider dashboard panel. The chain is accurate and it describes about a fifth of the incident.
WHY did checkouts fail? -> v412 sent an address format one provider rejects. WHY was that format sent? -> A validation refactor tightened the formatter. WHY did the refactor ship? -> Tests passed; no test covers non-US addresses. WHY is there no such test? -> The fixture set was built from US sample data. WHY was the fixture set built -> The service launched US-only and the fixtures that way? were never revisited after expansion. TERMINUS: stale test fixtures. ACTION: add non-US address fixtures. NOT REACHED BY THIS CHAIN - page threshold (5%) sat above the impact this bug produced (3.1%) - rollout went to 100% with no canary window - no per-provider error breakdown on the dashboard: 11 minutes lost - rollback required a manual approval step
Where each technique is honest
There is no winner here. Each technique makes a different claim about the shape of the failure, and the skill is matching the claim to the incident in front of you.
You have a timeline and a set of observations. How do you structure the analysis?
when A single factor is clearly dominant and you want depth on it — a specific bug, a config value, an expired credential.
cost Represents only one branch. If you use it as the whole analysis, you will find one fix and ship it as if it were complete.
when The default for most production incidents. Several conditions held at once and each is independently removable.
cost Produces more findings than you can fund, forcing an explicit prioritisation argument.
when Complex incidents, especially cascades where a mitigation became a cause (Cascading Failure: When the Response to Failure Causes More Failure).
cost Harder to read and to summarise; needs a facilitator who will not let the diagram become tidy at the expense of true.
when Small incidents where the value is the record, not the analysis, and detection or response is the only interesting part.
cost No causal claim at all, so a pattern that only appears across incidents will not be visible from this one.
when A well-understood component with enumerable failure modes — a storage layer, a certificate lifecycle, a failover path.
cost Requires the failure space to be enumerable, which is exactly what application-level bugs are not.
Rules that keep the technique useful
The distinction that matters most is between a step supported by evidence and a step supported by a plausible story. Chains are fluent, and fluency is persuasive out of proportion to its accuracy — which is the whole reason to be strict about what each step rests on.
- Every step names the evidence it rests on, or is marked explicitly as a hypothesis.
- Where a step has two true answers, record both and follow both. Branches are the finding, not a mess.
- Stop at something you can change, however many steps that takes.
- A human action is never a terminus — it is a doorway into the system questions.
- The chain is an input to the postmortem, not its structure.
The pods restarted, so the service must have been under memory pressure, which suggests the new release has a leak, which is probably the caching change, which means we should revert the caching change.
The pods restarted: kubelet events show exit code 137 (`OOMKilled`), memory limit 512Mi. Memory usage graphs show a step change at 14:02, matching the v412 deploy annotation. Heap profile from a surviving instance shows the response cache growing without eviction. The caching change in v412 removed a size bound. Each step names the artifact it rests on.
Both chains reach the same destination. The first is a hypothesis wearing the clothes of an analysis, and it would have been equally fluent if the cause had been a sidecar's memory limit instead (OOMKilled: Over the Memory Limit). Only the second one would have noticed it was wrong.
How to do it properly
Most important first.
- Use it to deepen a single factor you have already identified, not to structure the whole analysis.
- At each step, ask whether there is more than one true answer. If there is, you have found a branch — record both and continue on each.
- Stop when you reach something you can change, not when you reach five. Sometimes that is two steps; sometimes seven.
- Never let a chain terminate on a person. If it arrives at a human action, that is a signal to switch to the system questions (Postmortems).
- Prefer explicitly multi-branch techniques when the incident is complex: a factor list with counterfactuals, or a causal diagram with several parents feeding the outcome.
- If your incident template mandates five whys, fill it in for the dominant factor and carry the rest of the analysis in the body. Do not let the form decide the shape of the finding.
How much can this affect
Every production change has a blast radius. Stated as a scale so it is comparable between changes rather than adjectival — and paired with what actually contains it, because a wide scope with a real containment mechanism is a different situation from a wide scope with none.
Contained by nothing directly — it is a method error that produces incomplete fixes, so the damage appears as recurrence rather than as an event.
What can go wrong
- The chain arriving at "the engineer was not careful enough", which is the technique running out of system to describe and continuing anyway.
- Five whys performed as ceremony, with the answers written after the conclusion has been agreed.
- A terminus so abstract it is unactionable — "we have a culture of moving fast" — which is where chains go when nobody wants to name a mechanism.
- Depth mistaken for correctness. A five-step chain of confident guesses is more persuasive and less true than a two-step chain of checked facts.
- Branches discovered and then discarded to keep the diagram tidy, which loses exactly the factors that were not already obvious.
- "Five whys is wrong and should never be used." It is one technique with a narrow good use: pushing past the first answer on one factor. The error is treating it as universal (Postmortems).
- "If we ask why enough times we always reach the true cause." You reach the end of one branch. Which branch you were on was decided at the first step.
- "The last answer in the chain is the root cause." It is where this particular traversal stopped, which is usually where the group ran out of knowledge or appetite.
- "Five is the right number." It is a memorable number from a manufacturing context, not a property of causation.
Operating it
Evidence is the signal, not the intention. Rollback is sometimes 'you cannot, and that is the point'.
- Each step in the chain is supported by something checkable — a log line, a config value, a deploy record — not by a plausible inference.
- Chains that hit a human action continue into system questions rather than terminating.
- The postmortem contains more findings than the chain does, because the chain was one input rather than the method.
- If an investigation has followed a chain to a confident but unsupported conclusion, the recovery is to return to the timeline and re-derive the factors from artifacts. Chains are cheap to redo and expensive to believe.
- Automate the inputs a good chain needs: change correlation, dependency health during the window, and the ability to query state as it was rather than as it is now (Change Correlation).
- Do not automate the chain. A generated why-chain is a fluent narrative with no way to distinguish an inference from a fact, and it will be read as an analysis.
- It is genuinely easy to teach and run, which is why it spread. Techniques that represent multiple causes honestly need more facilitation and produce messier artifacts.
- A chain communicates well to people who were not there. A factor graph is more accurate and harder to read, so summaries drift back towards chains.
- Abandoning it in an organisation whose incident tooling has a "root cause" field means every incident record carries a claim you do not endorse.
Where this applies
This domain is unusually tool- and organisation-dependent. These labels say what each claim is specific to, and what a different platform, provider or organisation does instead.
- GENERALThe critique is about causal structure in redundant systems and applies wherever failures are conjunctive. In genuinely linear processes — a build script, a single-threaded batch job — a chain can be a fair representation.
- ORG-SPECIFICMany incident management tools and quality processes hard-code a five-whys field or a single root-cause field. Whether you can decline to use it is an organisational question, not a technical one.
Where the depth lives
This domain teaches delivery and operation, and hands the mechanism off to the domain that owns it.
- — Testing & Reliability Engineering — reproducing a failure as the strongest possible evidence for a causal step, and why production incidents so rarely offer it.