Finding the Hidden Trigger Behind an On-and-Off Fault

Why this matters

An intermittent fault is not random, even when it looks it. Something turns it on and off, and that something is the trigger. Find the trigger and the fault stops being a mystery. Miss it and you replace good parts, close the ticket, and get the callback the next time the trigger comes back. This card is the mental model for hunting a trigger you cannot yet see, across any trade.

The core idea: intermittent means triggered, not random

A fault that comes and goes has a condition attached. When the condition is present, it fails. When it is absent, it works. "Random" almost always means the condition is real but sits outside anyone's attention, either because it is physically invisible (a voltage sag, a dew point crossed) or because it is so ordinary that nobody connected it (the dishwasher runs at the same time every night). Your job is not to catch it in the act by luck. It is to name the condition.

The five families of triggers

Most intermittents belong to one of five families. Sorting the complaint into a family narrows the hunt from everything to one thing.

Family The hidden condition Cross-trade tells
Thermal A temperature threshold crossed Fails after long runtime, on the hottest afternoon, or only on cold mornings
Moisture Humidity, condensation, or intrusion Fails after rain, on muggy days, or where a cold surface sweats
Load / demand Another load drawing on a shared resource Fails only when a second appliance runs, or at peak draw
Motion Vibration, flex, or thermal cycling working a connection Comes and goes when something is tapped, moved, or heats and cools
Time / cycle An automated schedule or an accumulating quantity Fails at a clock time, on a certain day, or after a set interval

The co-occurrence test

Here is the rule that turns a hunch into a diagnosis: the trigger is the one variable that is present at every failure and absent every time the system works. Both halves matter. A variable that is also present when the thing runs fine cannot be the trigger, no matter how suspicious it looks. That is why one failure proves nothing. You need failures to compare against non-failures. A single event that lined up with one condition is a coincidence until it repeats under the same condition and stays absent otherwise.

Turn the customer into your instrument

The customer is on site around the clock. You are there for an hour. Use them. Instead of "call me when it breaks," hand them a short, specific list to note at the next failure: exact time, what else was running, the weather, who was home, and what they had just done. A precise failure report is the next best thing to catching it yourself, and it points your return straight at the condition instead of at another parts swap.

Reproduce the trigger, do not wait for it

Once you suspect a family, recreate the condition on purpose rather than waiting for it to recur. Warm a connection to test a thermal trigger, load the circuit or run the suspected co-appliance for a demand trigger, gently flex or tap for a motion trigger, or raise local dampness safely for a moisture trigger. Then have your eyes or your meter on the suspect at the moment it fails. A fault you can summon is a fault you can find.

When the trigger is off the property

If nothing inside the building correlates, widen the boundary. Shared infrastructure triggers plenty of "unfindable" faults: utility voltage and time-of-use switching, pressure changes on a shared water main, a shared neutral with a neighbor, or electrical noise from nearby equipment. When the property is clean, the trigger may be arriving from outside it.

References

  • Trade-standard intermittent-fault diagnosis practice
  • Manufacturer operating-condition and environmental specifications
  • See related: It Only Fails Under a Condition Nobody Noticed (Decision Tree); Using a Timeline to Expose a Hidden Trigger