The 5 Whys root cause technique

WHAT THIS TESTS Whether you can move from a surface symptom to a fixable systemic cause, and whether you know the technique's limits.

A GOOD ANSWER COVERS The 5 Whys is an iterative questioning method: you state the problem, ask why it happened, then ask why of that answer, and repeat until you reach a cause you can durably address. Five is a guideline, not a rule, sometimes it takes three, sometimes seven, and real failures often branch into multiple contributing causes, so you may follow several chains. The goal is a systemic fix, not a person to blame, so an answer like the engineer forgot is a signal to ask why the system allowed forgetting. You stop when further whys leave engineering control or when you have an actionable change.

COMMON WRONG ANSWERS Stopping at the first symptom, for example just raise the pool size. Treating five as mandatory. Concluding with human error and stopping there.

LIKELY FOLLOW-UPS When does 5 Whys break down for complex cascading failures? How do you handle multiple parallel causes? How is it different from a fishbone diagram?

ONE CONCRETE EXAMPLE The service returned errors. Why? The connection pool was exhausted. Why? A slow downstream query held connections open. Why? A missing index made the query scan the whole table. Why? The index was dropped in a migration without review. Why? There was no schema-change review gate. The fix is not just raising the pool size, which only delays the next exhaustion; it is adding the index and instituting a schema-change review gate, the systemic cause the chain surfaced.