The Difference Between an Intermittent and a Condition-Dependent Fault

Why this matters

"It only does it sometimes" hides two completely different faults that call for opposite strategies. One is genuinely intermittent: it fires at random and you cannot make it happen on command. The other is condition-dependent: it fires every time a specific condition is present, and it looks random only because you have not identified the condition. Confuse the two and you waste the visit. You sit and wait for a fault that would appear on demand if you recreated the trigger, or you burn hours trying to force a fault that has no trigger to force. Sorting which one you are facing is the first real move, before any meter comes out.

The core distinction

• Intermittent means the fault has no reliable trigger you can control. It comes and goes on its own schedule, driven by something transient, borderline, or internal that does not track any input you can set. Present the same conditions twice and you get the fault once.
• Condition-dependent means the fault is deterministic: whenever a specific condition holds, the fault appears, and whenever it does not, the system is fine. It only seems intermittent because the condition itself comes and goes. Recreate the condition and the fault is there every time.

The dividing line is repeatability under a known condition. If matching a condition reliably brings the fault, it is condition-dependent no matter how unpredictable it felt. If nothing you can set brings it reliably, it is truly intermittent.

How to tell which one you have

Two moves separate them, and both come before instrumentation:

• Interview for a pattern. Ask when it happens in terms the customer can answer: what time, what weather, what was running, what were they doing, how long after startup. A fault clustered around any of those, mornings, cold snaps, heavy load, a specific appliance running, is waving a condition at you. A fault with no pattern anyone can name is a candidate for truly intermittent, though absence of a pattern often just means nobody looked for the right one yet.
• Try to reproduce by recreating the suspected condition. Put the system into the state the interview pointed at, load it, cool it, wet it, run the neighbor, and see if the fault comes. If it does, and comes again when you repeat, you have a condition-dependent fault and you have found its trigger. If the system stays clean through every condition you can produce, intermittent moves up the list.

Why it changes your whole approach

The two faults are worked in opposite directions:

• A condition-dependent fault is solved by recreating the condition so you can measure the system while it is faulting. Once the trigger is in your hand, this becomes an ordinary diagnosis: hold the condition, take live readings, watch what goes out of range as it appears. The hard part was finding the trigger, not the fault.
• A truly intermittent fault is solved by capture, because you cannot summon it. You instrument the system to record the moment it happens and leave the recorder in place, or you set up an extended-observation plan. You are trading the ability to force the fault for the ability to catch it when it forces itself.

Spending capture effort on a condition-dependent fault, or trying to force a truly intermittent one, is the core waste this distinction prevents.

The trap: it is condition-dependent and you missed the condition

Most "intermittent" faults are condition-dependent faults whose trigger has not been found. Before you commit to a capture strategy, which is slower and more expensive, do the work to rule out a hidden condition, because finding the trigger converts the whole job to a fast on-demand diagnosis. Widen the interview beyond the obvious drivers to combined conditions, cold and heavy load together, humidity plus a specific cycle, a neighbor running at the same time, since a fault that needs two conditions at once looks far more random than one that needs a single trigger. Only after you have genuinely hunted for a trigger and come up empty should you accept true intermittency and switch to capture.

Working each one

• Condition-dependent: name the trigger, recreate it deliberately and safely, then diagnose live under the fault. When you provoke a condition, lead with the hazard: never force load, temperature, pressure, or a wet condition onto a system without first controlling the shock, burn, pressure, or combustion risk that condition may raise.
• Intermittent: deploy capture, a data logger, a recording meter, a flagged event the customer can trigger, or a defined recheck window, and set expectations that the answer arrives when the fault does, not on this visit.

References

• Trade-standard practice for intermittent-fault capture and controlled reproduction
• Manufacturer diagnostic and operating-condition specifications
• See related: How to Log an Intermittent Fault Over Days; The Fault Only Happens in Certain Weather (decision tree)