Use the 5 Whys without forcing an incident into one cause

The point of causal inquiry is to produce a defensible risk decision. A fifth answer does not establish that the resulting intervention will change the failure. Work backward from the exposure you intend to reduce, then ask which causal links and acceptance evidence would justify that claim.

The 5 Whys can move that discussion toward mechanisms. It becomes less useful when five answers are treated as a requirement, or when the team chooses a single chain because a template has room for only one.

Ask for evidence behind each link

Consider a hypothetical review that ends with “insufficient testing” and creates a ticket to add a test. The new test passes, but nobody has checked that it reproduces the incident’s concurrency condition. The task is delivered while the risk claim is unsupported. Return to the mechanism and design the test around the condition that caused the failure.

Each answer needs evidence. Request traces could establish repeated attempts; configuration could establish the retry limit; load tests could explore whether the same settings reproduce the amplification. If the records cannot distinguish a query regression from a cache miss storm, preserve both hypotheses rather than writing the more plausible one as fact.

Stop extending a causal chain when evidence runs out, and keep delivery separate from proof that the chosen intervention treats the identified exposure.

Time-limited reviews cannot resolve every uncertainty. Record an open question and its consequence when evidence runs out; an honest boundary is more useful than a tidy unsupported cause.

The causal structure may branch. A deployment could increase query cost while a missing concurrency limit allows the resulting backlog to spread. Repairing either condition may help, but they are separate opportunities with different costs and residual risks.

Ask what would disprove each proposed link. If retries amplified the overload, a reduction in retries should change demand under otherwise comparable conditions. If demand does not change, inspect whether another caller or background task supplies the load. This turns a plausible narrative into an investigation that can revise itself, instead of making every new observation fit the first explanation offered.

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.

Examine the response as well as the trigger

A technical explanation does not explain why mitigation took forty minutes. Run a separate inquiry into the response, using the information available to people at the time. Did the alert expose the affected operation? Was the database team already handling another incident? Did the documented rollback require an unavailable approval?

Google’s blameless postmortem approach supports examining the conditions around decisions. “The engineer should have noticed” skips the more useful question of what would have made the condition noticeable and actionable.

Avoid replacing blame with another certainty: the organization is not automatically the sole cause either. Technical behavior, workload, incentives, documentation, and chance can interact. Describe the contribution supported by the record.

Stop when the next investigation has a purpose

A practical stopping point is a mechanism with a proposed intervention and a way to evaluate it. That does not mean deeper causes have been disproved. Record unresolved questions if they could alter the remedy, and assign further investigation when its likely value justifies the work.

For the retry example, “add jitter” is incomplete if unlimited concurrency still overloads the database. A bounded retry policy, deadlines, and a concurrency limit may need to be tested together. Define a representative degraded-dependency test and observe load, rejected work, and recovery time.

Some useful findings do not produce an immediate code change. Learning that two teams use different definitions of recovery may warrant a measurement agreement. Preserve that insight without forcing it into a claim that one new control will prevent every recurrence.

Leave a record someone can challenge

Write the finding as evidence, interpretation, and proposed action. For example: traces show repeated requests after timeouts; the team believes retries amplified demand; a controlled test will compare bounded retries against the previous policy. Readers can then see which part is known and which part remains to be tested.

Move material unresolved exposure into the risk registry. The quality of the review lies in the better question or intervention it produces, not in reaching the fifth answer.