Distinguishing Coincidence from Causation in Fault Timing

Why this matters

Every customer hands you a timeline: "it broke right after the storm," "it started when the new dishwasher went in," "it's been doing this since the last tech was here." Some of those timelines are the actual cause. Many are just two unrelated events that happened to land near each other, and a tech who accepts every timeline at face value ends up chasing the wrong fault, quoting the wrong repair, or blaming the wrong party. Learning to separate a real correlation from a coincidence is a core diagnostic skill, not a soft skill, because it changes what you test first.

Why humans are bad at this by default

People are pattern-matching machines, and the brain treats "before" as "because of" by default. If a unit fails the same week as a storm, a renovation, or a new appliance install, the mind links them automatically, even when the real cause is unrelated wear that simply reached its breaking point that week. Your job is to slow that instinct down and test the link instead of accepting it.

Three questions that separate correlation from causation

1. Is there a plausible mechanism? A power event can plausibly damage electronics. A new appliance on the same circuit can plausibly overload a marginal breaker. A storm can plausibly introduce moisture. But "the neighbor got a new car the same week" has no plausible mechanism connecting it to your customer's failed unit, no matter how confidently it's reported. If you cannot describe a physical path from the claimed event to the failure, treat the timing as coincidental until proven otherwise.

2. Does the failure pattern match what that cause would actually produce? A surge produces a specific signature: usually electronic or control-level damage, sometimes visible arcing or a blown protective device, and often affects more than one device on the same circuit. A worn mechanical part produces a different signature: gradual noise or performance decline before final failure, wear marks, and a single point of failure unrelated to any external event. If the customer blames a storm but the failure looks exactly like ordinary wear-out (a bearing seized, a valve seat eroded), the timing is probably coincidence: the part happened to reach end of life during a memorable week.

3. Would this fault have happened anyway, on a different timeline? Ask yourself whether the component was already near its expected service life or already showing prior symptoms. A five-year-old part failing during a storm needs real evidence to blame the storm. A part well past its typical life failing during a storm is most likely just wearing out, with the storm as an unrelated coincidence the customer's memory has stitched together.

The single strongest signal: does more than one thing fail at once

When a genuine external cause (a power event, a water event, an install error) is responsible, it usually affects more than one component or system, because the cause is upstream of a single part. One isolated component failing, with everything else around it fine, is a weaker case for an external trigger and a stronger case for ordinary component failure that happened to coincide with a memorable date.

How to talk to the customer about it

You do not need to argue the customer out of their theory to do good work. Acknowledge the timing they noticed, then explain what you are checking and why: "That's a good data point, I'm going to check whether anything else on that circuit was affected, because that tells us if it was really the storm or if this part was just due." This keeps the customer as a partner in the diagnosis instead of putting them on the defensive, while you still do the real work of separating the two possibilities.

When correlation turns out to be real

Do not swing so far toward skepticism that you dismiss a real correlation. If the mechanism is plausible, the failure signature matches, and other equipment nearby was also affected, document the timeline as supporting evidence in your notes and in the customer conversation. A defensible root-cause statement leans on a mechanism and a matching pattern, not just "it happened after X," but when both point the same direction, say so with confidence.

References

• Basic principles of root-cause analysis (5 Whys, fishbone/cause-and-effect method) as used in maintenance and reliability engineering
• See related: The Fault Started Right After an Outage or Surge (decision tree); A Customer Blames a Storm for an Unrelated Fault (decision tree)