The Fault You Can Reproduce but Can't Explain: Decision Tree

Why this matters

You trigger the fault reliably, every time, under the same conditions, but every reading you take during the fault comes back normal, and every component you check tests good. This is more frustrating than a fault you cannot reproduce at all, because reproducibility usually means you are close to the answer, yet the answer is not showing up where you are looking. The instinct to replace the most-suspected part anyway, just to move the ticket forward, is exactly how a callback gets created, because a part that tests good and gets replaced anyway is a coin flip, not a diagnosis.

Start here: are you measuring the right thing, at the right moment

Before assuming the cause is exotic, check the basics of how you are testing.

1. Confirm your readings are taken during the actual fault condition, not just near it. A test taken a few seconds before or after a transient fault clears will read normal even though the fault is real.
2. Confirm you are measuring at the point closest to the actual failure, not a convenient point nearby. A connection two inches downstream of the actual fault point can read clean while the fault point itself is not.
3. If your test timing and location are both solid and the reading is still clean, continue below.

If the fault is triggered by a specific condition (load, temperature, position, moisture)

This is the most common shape of a reproducible-but-unexplained fault, and it points at something that only manifests under that specific condition and self-corrects once conditions change.

• A connection or component that is fine at rest but fails under thermal expansion or load will test perfectly clean with everything powered down or idle. Test it while actively holding the trigger condition, not before or after.
• A fault tied to physical position or vibration (a wire that only opens when the unit is running and shaking, a joint that only leaks under pressure) needs to be tested while physically reproducing that position or vibration, a static test misses it entirely.
• A fault tied to moisture or humidity can vanish the moment you open a panel and the fault point dries or the meter probe disturbs it. Test in place, disturb as little as possible, and consider whether opening things up to inspect is itself clearing the condition you are trying to catch.

If the fault reproduces under a condition you cannot easily hold while testing

Some trigger conditions are hard to test live, load is dropping the moment you probe it, temperature is changing, access is blocked while running.

• Use a logging or recording approach instead of a live spot-check: a data logger, a recording meter, or a simple before/after comparison across the fault event, so you capture the condition even if you cannot watch it happen with a meter in hand.
• If logging tools are not available, try to narrow the trigger further (exact threshold, exact position, exact duration) so your live test window gets longer and easier to catch mid-fault.

If every test during the fault condition still comes back clean

This is the point where the cause is likely intermittent at a scale your tooling is not catching, a connection that opens and closes in a fraction of a second, a fault that only exists for milliseconds. Consider:

• A different test method that catches transients your normal tool misses (continuity with a tap or vibration test instead of a static reading, a scope instead of a multimeter, a leak-down test instead of a static pressure check).
• A visual and physical inspection under the trigger condition, looking and listening rather than only measuring, sometimes you catch the fault by ear or by touch (a spark, a click, a hot spot) before your meter would register it.
• Substitution testing: if you have a known-good spare and the fault reproduces reliably, swap the most-suspected component and re-test under the same trigger condition. This is different from replacing on a hunch; it is a controlled test with a clear pass/fail outcome, and if the fault stops, you have your answer even without ever capturing a bad reading directly.

What not to do

Do not replace the most-suspected part and call the ticket closed just because the fault happened to stop for one test cycle. An intermittent fault can go quiet on its own for reasons unrelated to your fix. Re-test under the original trigger condition multiple times before declaring it resolved, and tell the customer honestly if you are closing it on a substitution test rather than a captured bad reading, so a repeat visit is not read as a wasted repair.

References

• Trade-standard practice for intermittent-fault diagnosis and data-logging techniques
• Manufacturer documentation on transient fault testing where available
• See related: The Fix That Only Worked Temporarily (Decision Tree), Why the Obvious Fix Sometimes Isn't the Cause