Why a 5 Whys investigation can branch

A postmortem concludes that testing was insufficient. A new test is added, passes and closes the action item. Yet if the original failure required overlapping requests and the new test runs them one at a time, the team has completed work without answering the question that made the work necessary.

This hypothetical mismatch is a useful test of the 5 Whys itself. The method works backward from an event through contributing causes, but five is an invitation to look further rather than a required chain length. Its value appears when the questions lead to an intervention whose effect can be examined, including the possibility that the explanation was wrong.

What connects this answer to the one before it?

For the added test, concurrency is the proposed connection. If overlapping requests caused the failure, the reviewer needs to see how the test creates overlap and which behavior it observes. A passing sequential test may be useful, but it does not establish what happens under the condition the incident depended on. Asking for that link turns “insufficient testing” into an engineering question.

If repeated attempts contribute to the overlapping demand, traces may establish those attempts, configuration may show the retry limit, and a load test may explore whether the settings reproduce that demand. The retry evidence still may not distinguish a query regression from a cache-miss storm. Both then remain hypotheses, and the next investigation needs to separate them rather than choose whichever produces the tidier story.

A causal chain can stop at an unresolved question, while completion of a fix remains distinct from evidence that the fix addresses the failure. The completed test ticket answers whether the work was done. A test exercising the relevant concurrent behavior answers a different question about the failure mechanism.

A time-limited review may leave questions unresolved; record their consequences and the evidence still needed rather than supplying an unsupported final cause. That boundary can make the next investigation more productive because it identifies exactly where knowledge stops.

Evidence may also branch. A deployment can increase work per query while missing concurrency limits allow more simultaneous work into the database. Either change may help, but each treats a different contribution and leaves a different remainder. Keeping both paths visible lets the team choose deliberately instead of squeezing them into one root-cause label.

The explanation becomes stronger when a proposed link can be challenged. If retries amplify overload, reducing them under otherwise comparable conditions should change demand. If it does not, another caller or background job may explain the load. That result improves the investigation by changing the hypothesis, even though it frustrates the original story.

A plausible failure mechanism can branch

Read diagram description

Illustrative hypothesis, not a confirmed incident: expensive queries and unconstrained concurrency can both contribute to overload. Timeouts and retries may then amplify demand. Test each proposed link against evidence. Diagram labels: Higher query cost: More work per request; Missing concurrency limit: More simultaneous work; Database slows: Requests take longer to complete; Deadlines expire: Clients may start retry attempts; Retries add demand: Additional attempts can worsen the slowdown.

The trigger may not explain the time to mitigation

A technical account of overload can still leave a long response interval unexplained. In a hypothetical forty-minute response, the useful questions include whether the alert named the affected operation, whether the database team was covering another incident and whether rollback needed an unavailable approver. Each concerns the options people actually had at the time.

Google’s blameless postmortem approach supports examining those conditions. Saying the engineer should have noticed stops before asking what would have made the problem both visible and actionable. A new signal, a staffed escalation path and accessible authority solve different omissions.

The same evidence standard applies to organizational explanations. Workload, incentives, documentation and chance may contribute, but replacing an unsupported claim about an individual with an unsupported claim about the organization does not improve the analysis. Describe the contribution the records can support and leave the remainder open.

When the next experiment is clear enough

A practical stopping point is a plausible mechanism, an intervention and a way to evaluate it. This does not disprove deeper causes. Unanswered questions that could change the remedy remain in the record, with further investigation chosen where its likely value justifies the work.

For retries, the next experiment might compare a bounded retry policy, deadlines and concurrency limits under a degraded dependency. Jitter alone may spread requests in time while leaving unlimited concurrent demand. Observing load, rejected work and recovery time shows which part of the proposed mechanism the treatment changed and what remained.

Not every useful finding ends in a code patch. Two teams using different definitions of recovery may need a measurement agreement before they can judge the same intervention consistently. Preserving that result is more useful than forcing every investigation to promise a control that prevents all recurrence.

A finding separates observation from explanation

A finding can separate evidence, interpretation and action in ordinary prose: traces show repeated requests after timeouts; the team believes those retries amplified demand; a controlled comparison will test a bounded policy against the previous one. A later reviewer can see what is established and which part the experiment is meant to resolve.

Material unresolved exposure belongs in the risk registry, where it can survive beyond the review. The question count need not survive with it. What matters is the improved decision or test the inquiry produced.

The concurrent-request test needs to create the overlap that the original explanation depends on. If the failure no longer appears, the result supports that intervention under those conditions. If demand remains unchanged after retries are limited, the investigation needs another explanation for the load. Either result is more useful than a fifth answer chosen simply to finish the chain.