Intermittent faults defeat most technicians because the car won’t misbehave on command. The fix isn’t better luck — it’s a systematic approach to capturing evidence when the fault happens and recreating it when it doesn’t.

Why intermittent faults are different

A permanent fault is a debugging problem. An intermittent fault is a physics problem: something changes between pass and fail states, and your job is to identify what. That shift is almost always triggered by one of four conditions:

Phase 1 — capture evidence first

The single biggest mistake is touching anything before gathering data. Every time you unplug a connector “to check it,” you potentially alter the fault condition, clear volatile memory, and lose the one piece of evidence that would have pointed to the cause.

1. Read and photograph all DTCs before clearing them. Note any pending and history codes alongside confirmed ones — they tell different stories.
2. Pull freeze frame data for any stored fault. Record vehicle speed, load, coolant temp, and fuel trim at the moment of failure.
3. Interview the driver properly: does it happen hot or cold? At speed or at idle? After a car wash? On rough roads? This narrows your trigger category immediately.
4. Check the DTC failure record counter if your scan tool supports it. A fault that has triggered 50 times versus 2 times calls for different urgency in your approach.

Phase 2 — set up live monitoring

The goal is to have the vehicle instrumented and recording before you attempt reproduction. Useful channels depend on the symptom, but a solid default setup includes:

• Relevant sensor PIDs (voltage, temperature, pressure — whatever feeds the suspect circuit)
• Misfire counters per cylinder if misfires are involved
• Battery voltage and charging system output
• Any actuator command vs feedback pairs (e.g., throttle position commanded vs actual)

An oscilloscope captures faster events that PIDs miss. If you suspect dropouts on a crankshaft sensor or a brief open in a trigger circuit, you need the scope — scan tool data logging typically samples at 5–20 Hz and will miss a 50 ms glitch entirely.

Phase 3 — reproduce the fault deliberately

Random road testing is the slowest path to a diagnosis. Use the freeze frame and driver interview to construct a specific test protocol, then apply targeted stress to the suspect trigger category.

Vibration / mechanical

• Wiggle harnesses while watching live data. Focus on known flex points: door aperture wiring, engine bay looms near hot or moving components, any harness running close to an exhaust.
• Rap connectors and sensors with a rubber-tipped hammer. A fault that reproduces on percussion is mechanical.
• For suspected broken conductors inside undamaged insulation, use a continuity tester while flexing the harness — a conventional multimeter will catch this more reliably than a scan tool PID.

Thermal

• Heat soak a suspected sensor or module with a heat gun (keep well below component ratings — 60–70°C is usually sufficient). Watch live data for the moment a value shifts.
• Cold spray can confirm the inverse: a component that fails hot and recovers cold will often fail immediately when sprayed cold after you’ve made it fail hot.
• Allow a full cold start if the fault only happens on a warm engine — don’t shortcut to operating temp.

Moisture

• Mist suspect connector ingress points with water. Never spray directly into a live ECU or module — target connectors, grommets, and exposed terminals.
• Inspect connector faces under magnification for green or white corrosion. Corrosion is not always visible macroscopically.
• Check for evidence of water tracking: staining or mineral deposits inside a connector body indicate previous ingress even if it’s dry now.

Load / voltage

• Load test the battery and charging system before anything else if the symptom involves low-voltage DTCs, resets, or comms faults.
• Command all accessories on simultaneously while monitoring battery voltage. A marginal charging system that copes at idle may drop voltage significantly under load.
• Test earth continuity under load, not just static resistance. A connection that reads 0.1 Ω with a multimeter can show 0.8–1.2 V drop under 20 A of current — enough to cause module faults.

Terminal tension: the most commonly missed fault

Loose terminals cause a disproportionate share of intermittent faults, and a visual inspection will not find them. A terminal that looks correct, clicks in correctly, and reads continuity correctly can still have insufficient pin tension to maintain contact under vibration or thermal cycling.

The test is a firm pull-out force check with a terminal pick tool — each terminal should resist extraction. If a wiggle test reproduces the symptom, always check tension before condemning the sensor. Replacing a sensor into a connector with tired terminals will produce a comeback within weeks.

Phase 4 — verify the repair, not just the absence of symptoms

An intermittent fault that disappears after a repair might have disappeared anyway. Verification must be stronger than “it hasn’t come back.”

1. Reproduce the original stress condition after the repair — same temperature, same load, same vibration input — and confirm the fault no longer appears in live data.
2. Log the same PID channels from your monitoring setup and compare before/after data. A repaired terminal connection should show stable voltage where there were previously dropouts.
3. Confirm freeze frame data is not accumulating new events after a road test that replicates the original fault conditions.
4. Document your findings with timestamps, channel screenshots, and the specific repair performed. An undocumented intermittent repair is a comeback waiting to happen.

Quick reference

Related articles

• Symptom vs DTC: which one should lead your diagnosis
• How to use OBD-II freeze frame data to find the root cause
• How to perform voltage drop testing step-by-step
• How to test engine and chassis grounds
• Why low voltage causes multiple DTC codes

Data logging and graphing for intermittent faults

A scan tool that only shows current live data values is a limited tool for intermittent diagnosis. A fault that appears for 200 milliseconds during a road test is invisible on a live data display that refreshes once per second. Data logging — recording multiple PIDs simultaneously over time — is the correct approach. Modern scan tools and most vehicle communication interfaces support logging at 2–10 samples per second per PID; keep the logged PID list short (typically four to six parameters) to maximise sample rate.

Log the parameters most likely to reveal the fault: RPM, MAP or MAF value, throttle position, and the signal most closely related to the stored code. If the fault is an oxygen sensor code, log both upstream and downstream O2 voltages. If the fault is a misfire code, log misfire counts per cylinder. Review the log file after the test drive and look for value spikes, dropout events (signal going to zero or 5V momentarily), or correlations between two parameters — for example, a brief MAP signal dropout that occurs exactly as a rough idle event is noted will confirm the MAP sensor as the fault source even if the code was not stored during that particular event.

Frequently asked

My scan tool shows no current faults. Where do I start?

Check history and pending codes first — many modules store fault events that don’t set a current DTC. If history is clean, you’re in fault-induction territory: use the driver interview to identify the trigger condition and set up monitoring before attempting to reproduce.

Should I replace the most likely component while I have it apart?

Only if your live data shows that component or its circuit changing at the moment of the symptom. Parts replacement without captured evidence is a guess. On intermittents, guesses are expensive — the fault may not return, you can’t verify the repair, and the real cause remains.

The fault only happens at road speed. How do I log it safely?

Set your scan tool to record continuously and trigger a snapshot on DTC set. Some tools allow a second technician to ride along and monitor; others allow the driver to manually trigger a snapshot. Alternatively, reproduce on a brake-loaded dynamometer if available. Never attempt to monitor a scan tool while driving alone.

When should I suspect a module rather than wiring?

After confirming supply voltage, ground integrity, and signal wiring are correct under the fault conditions. Also consider a module when the symptom is erratic rather than consistent with a specific trigger, when other modules on the same CAN bus are affected simultaneously, or when the fault follows a pattern that correlates with ignition cycles rather than physical conditions.