Proximate cause versus root cause

WHAT THIS TESTS Whether you understand causal layers and why durable reliability comes from fixing systemic conditions, not just the latest trigger.

A GOOD ANSWER COVERS The proximate cause is the immediate, surface-level event that directly preceded the failure, the thing that broke. The root cause is the deeper systemic condition or missing safeguard that allowed that proximate event to escalate into an incident. There can be a chain between them, and often multiple contributing factors. Addressing only the proximate cause fixes this one occurrence but leaves the system equally vulnerable to the next variant, so the failure mode recurs. Addressing the root cause neutralizes the whole class of incidents. For long-term reliability you want recurrence prevention, which means investing in the systemic fix even when it is more expensive than patching the symptom.

COMMON WRONG ANSWERS Treating proximate and root cause as synonyms. Declaring victory after fixing the immediate trigger. Confusing root cause with whoever was on the keyboard.

LIKELY FOLLOW-UPS Can an incident have multiple root causes? How does this relate to the 5 Whys? How do you justify the cost of root fixes to stakeholders?

ONE CONCRETE EXAMPLE A service crashed because a deploy shipped a config with a bad value, the proximate cause. Reverting that config fixes today's outage. But the root cause is that no validation or canary stage existed to catch bad configs before full rollout. If you only revert, the next typo causes the same crash. Adding config validation and a canary stage addresses the root, preventing the entire class of bad-config outages and delivering lasting reliability rather than a one-off patch.