The worst fault to chase is the one that clears before anyone reaches the panel. The terminal's tight again, the condensation's burned off, the noise source cycled off, and everything meters fine by the time you get there with a laptop. So the first job is never fix it. The first job is to make the fault leave a record, because you can't fix what you can't catch.
The operators often already know the pattern. Nobody wrote it down.
This is a field method for a maintenance tech, controls engineer, or reliability person who keeps getting handed the same complaint: it happened again, then it cleared, and nobody can find anything wrong. Read the order once, work from evidence rather than the last thing someone swapped, and if the fault has already cleared, skip straight to setting a trap.
Capture evidence before you touch anything
Turn on first-out or first-fault logging if it isn't already running. Most controllers and safety systems record which condition tripped first in a cascade, and one device faulting looks identical to ten until first-out tells you which one moved first. If your platform is old enough that it has none of that, note it and lean on an external trap instead, which I'll get to. Confirm your event and alarm timestamps are actually right, and synchronized if you've got more than one device: a PLC log reading 14:32:07 and a drive log reading 14:29:51 for the same event will send you chasing a phantom.
Trend the suspect signals, analog values, comms status bits, supply voltages, digital inputs, fast enough to catch what you're chasing. A once-a-second trend misses a 200-millisecond dropout completely, and even a 200ms sample can straddle and miss it. To reliably catch a glitch that short, sample well under 100ms, or better, arm a triggered capture that latches on the event instead of hoping a periodic sample lands on it.
Then ask the operators the boring questions and write down the answers: time of day, startup or steady running, wet weather, a big compressor kicking in nearby. They often already know the pattern and nobody wrote it down. I once burned two visits on a dropout that turned out to track a chiller in the next room cycling on; the operator had clocked the timing weeks earlier, I just hadn't asked.
The families of intermittent faults, and how they present
Intermittents cluster into a handful of recurring stories. A fault that correlates with vibration, machine motion, or a passing forklift, and comes and goes when nothing electrical changed, usually means a loose termination or a chafed conductor. Thermal imaging only catches a loose joint on a current-carrying power termination under real load; on a lightly loaded 24VDC signal terminal a bad joint dissipates almost nothing and images stone cold, so on those you want a millivolt-drop measurement across the joint or a wiggle-test with a trend running.
A fault that shows up in early morning after a cold night, or in humid weather, and clears once things warm up, points at condensation inside the enclosure, a failed heater, or connector corrosion. Wet, corrosive sites like composting and anaerobic digestion plants or water and wastewater facilities see more than their share of this family, because condensation and corrosion do the loosening for you. A fault that tracks with temperature, worse on hot afternoons or near a heat source, points at a marginal component drifting, a supply sagging when warm, or a stopped fan.
A reading that's noisy or jumpy with false trips and no real process change, especially if it started after new equipment went in, is almost always a ground loop or a VFD injecting noise onto a signal cable with the shield landed wrong. A device that drops off the network and comes back, with a comms alarm that self-clears, usually traces to a marginal cable, a flaky switch port, or two devices fighting over a duplicate IP address. And when multiple unrelated devices glitch or reset at the same instant with nobody having commanded it, suspect a shared supply sagging or a large load's inrush; a power-quality logger on the incoming feed earns its keep here.
A practical triage order
At the panel, work from cheapest and most common toward rarest and most invasive. Read the logs first, first-out, alarm history, drive fault buffers, and get the timestamp before you pick up a screwdriver. Look and smell: open the enclosure and check for water tracks, corrosion, a burnt smell, a heat-discolored terminal, a wire hanging by two strands. A lot of intermittents are visible if you actually look.
Check power and grounding, meter the control supplies under load and confirm the bonding path; a shield landed at both ends underlies a surprising share of "weird" faults and is quick to rule out. Check connections mechanically, tug-test and retorque to spec with power off, and thermal-image only where the joint carries real current, falling back to a millivolt-drop or wiggle-test on lightly loaded signal terminals. The longest intermittent I ever chased was one spade lug backed off a quarter turn; it only dropped out once the panel warmed up, and imaged warm the second I put load on it.
Then check comms, error counters, port stats, cable condition, and check the sensor or final element last, because instruments get blamed first and are usually innocent. If a step turns up something concrete, stop and pursue it; treat the order as a default, and if operators tell you it only happens in the rain, start with condensation and grounding instead.
Set a trap for the next occurrence
If it's already cleared, this is the real work: build something that's recording when the fault comes back. Trend the right signals fast enough, well under 100 milliseconds if you're chasing a roughly 200ms glitch, because sampling in the same range as the event aliases and misses it; better still, arm a triggered capture so the event latches itself. Latch the first-out so whatever tripped first is held until someone reads and clears it, because a self-clearing fault with no first-out record is a wasted occurrence.
If your controller has no first-out, event log, or triggered capture at all, and a large share of the installed base doesn't, bring your own: a standalone datalogger, a bench scope or meter with min/max and a triggered mode, a plug-in power-quality logger on the supply, or a spare fast input mirrored to a chart. Instrument the physical suspects too, a cheap temperature and humidity logger in the enclosure, a clamp meter with min/max hold on a supply, and write down what normal looks like on a good day so the bad-day trend is actually readable against something.
The one thing you never do to make it stop
An intermittent that keeps nuisance-tripping a protective function is exactly the one someone gets tempted to jumper out just to stop the calls. If a trip is genuinely spurious and the process never approached the protected condition, retuning that threshold or filtering the input is legitimate engineering, done deliberately and documented. Forcing a safety input, bypassing a safety relay, or strapping out an interlock to silence the alarm removes the protection while you still don't know why it fired. Treat every trip of a safety function as evidence, not noise, until you actually know what it's seeing.
Get the timestamp, the first-out, and a trend around the moment, and an intermittent turns into an ordinary fault you can chase. It's the faults that bounce between the controls vendor, the drive vendor, and the instrument supplier that stay unsolved longest, because each one tests their own box, finds it fine, and hands it back, while the fault lives in the seam between them. That's usually where a vendor-neutral look pays off.
I've written a deeper, sector-specific version of this same method for the wettest, most corrosive sites in chasing ghosts: diagnosing intermittent PLC faults that come and go, if that's closer to what you're actually dealing with. And every one of these visits costs real production time; the OEE and downtime cost estimator is a quick way to see what a recurring, unexplained stop is costing you across a year.
The printable field version of this guide, with the full symptom-to-check reference, is free in the resources library. If you're stuck in that handed-around loop on a fault that won't repeat, get in touch and tell me what the trap caught.