Using a Timeline to Expose a Hidden Trigger

Why this matters

When a fault will not repeat for you and no black box recorded it, you build the black box yourself. A structured timeline, failures logged alongside the conditions around each one, turns an unrepeatable intermittent into a pattern you can read. It is the most powerful tool there is for a hidden trigger, and it costs nothing but discipline. Most techs skip it and keep guessing, which is why the same intermittent gets three visits and three wrong parts.

When to build one

Reach for a timeline when the fault is intermittent, will not reproduce on demand, and has no onboard log to read. If the equipment records its own fault history, cross-check that first (see the local-fault-log article). The timeline is for everything that does not keep its own record: a nuisance trip, a pressure drop, a pool losing prime, an appliance that quits and recovers, anything where the only witness is whoever happened to be standing there.

Design the log: the columns that matter

A useful timeline is not "it broke again." It is one row per event with the candidate triggers recorded beside it:

• Date and exact time
• What happened, in the customer's own words
• Weather (temperature, rain, humidity, if any could matter)
• What else was running (appliances, pumps, heating or cooling)
• Who was home and what they were doing
• Anything unusual

Give the customer this as a short form on the fridge or in their phone, not a vague "call me when it happens." The structured columns are what make the pattern fall out later. A pile of "it did it again" notes with no conditions attached is almost useless.

Log failures and normals, over enough time

The common mistake is logging only failures. You need the quiet periods too, or you cannot tell a trigger from a constant. If "the dishwasher ran" shows up on failure nights and on trouble-free nights alike, it is not your trigger, and only the normal rows reveal that. Log long enough to collect several failures across genuinely different conditions. A few days is rarely enough if the fault shows up weekly; give it the span it needs to catch itself more than once.

Read it: the variable present at every failure, absent every normal

The trigger is the one condition present at every failure and absent every time the system behaved. Scan the columns: does any single variable line up with every failure row and none of the normal rows? That column is your suspect. If two or three line up, you have narrowed it to a short list to test rather than a whole property to search. This is the same co-occurrence logic a data logger uses; you are just doing it by hand.

The confounder trap

The sharpest hazard in reading a timeline: two variables that always move together cannot be separated by the log alone. Weekends and "kids home" always coincide. Rain and "heat off" might. If your suspect always travels with a second variable, the timeline can only point at the pair, not at which half is the cause. To split them you need one deliberate trial where they come apart, a weekday with the kids home, or the load run without the weather. Until they split, you have a correlation to two things, not a diagnosis.

One instance is not a correlation

A single failure that lined up with one event is a coincidence until it repeats. Resist closing on the first match, however clean it looks. The timeline earns its power from repetition, so demand at least a couple of independent failures that share the variable before you act on it. The discipline that makes this method work is refusing to be convinced early.

From correlation to proof

A timeline names a suspect. It does not convict one. Once the log points at a variable, reproduce it on purpose and measure at the moment of failure, with your eyes or your meter on the part you suspect. Correlation gets you to the right test. The test is what proves the cause. Hand off to the trigger-hunt and condition-reproduction methods once the timeline has done its job of pointing you there.

References

• Trade-standard practice for intermittent-fault logging and correlation
• Reliability practice on distinguishing correlation from cause
• See related: Finding the Hidden Trigger Behind an On-and-Off Fault; Cross-Checking a Local Fault Log Against the Customer's Timeline