How to Separate Runtime-Driven Faults From Ambient-Driven Ones
Why this matters
Both families produce the same customer sentence: "it only acts up when it is hot." One of them is about the weather and one of them is about the hour meter, and they lead to completely different repairs. Chase the weather and you insulate, shade, or oversize something that was never the problem. Chase the run time and you find the connection, the accumulation, or the capacity shortfall that is actually there. The separation costs you one structured conversation and one deliberately awkward test, and it is the highest-yield 20 minutes in intermittent work.
Step 1: Write down two clocks, not one
Before any tool comes out, build a small occurrence table with a column for each clock. Every reported failure gets a row.
- Runtime clock: how long had the system been running continuously when it failed, and how many starts had it made that day.
- Condition clock: what the outdoor temperature, humidity, wind, water temperature, or incoming supply was doing at that moment.
Skip this and you will interview the customer about weather, because weather is what they volunteer. They almost never volunteer run time, because nobody watches a machine run. Ask for both explicitly and you get two independent variables instead of one anecdote.
If the customer cannot give you run time directly, get it indirectly: what time did they turn it on, what time did it quit. Two clock times subtract into a duration and people remember clock times far better than durations.
Step 2: Ask the cold-start question
One question separates the families faster than anything else you can do on site.
"Has it ever failed within the first ten minutes after being off for a few hours?"
A firm no across many occurrences points hard at run time. The system is fine cold under every condition, which means the condition alone is not sufficient to cause the fault. Something has to accumulate first.
A yes, especially a yes on the worst days, points at condition. If it can fail cold when the weather is extreme, the weather is doing the work and run time is at most an accelerant.
An "I am not sure" is not a dead end. Convert it into a test: have them run the system first thing in the morning on the next hot day and note whether it fails before ten minutes. That is one observation the customer can genuinely deliver.
Step 3: Look at the spread, not the average
With four or more occurrences logged, compare how tightly each clock clusters. This is the whole analysis and it takes two minutes on the back of a work order.
A runtime-driven fault shows tight clustering on run time and wide scatter on condition. The same 40-ish minutes over and over, on mild days and hot ones alike.
A condition-driven fault shows the mirror image: wide scatter on run time, including very short runs, and tight clustering on condition, usually above or below a threshold value.
A mixed fault, which is common, shows the runtime figure shrinking as the condition gets more severe. Ninety minutes on a mild day, forty on a hot one. That still means the mechanism is accumulation, and the condition is just setting the starting point closer to the limit.
Judge the tightness in percentage terms, not raw units. A run-time spread of 14 minutes around a mean of 44 minutes is about a third of the mean, which is tight for customer-reported estimates. A run-time spread from 4 minutes to 2 hours is not clustering at all.
Step 4: Run long on the wrong day, on purpose
This is the confirming test and the step people skip because it feels like a waste of a mild afternoon.
Pick a day with the condition clearly absent, mild instead of hot, dry instead of humid, and run the system continuously past 1.5 times the clustered run-time figure. If the fault appears anyway, the condition is not required and you have proven a runtime mechanism. If the system runs clean well past the expected point on a mild day and fails at the same point on the next hot one, you have proven the condition is required and you are looking at a condition-driven or mixed mechanism.
Two things make or break this test. Run it in the exact mode and load the customer uses, because a system idling at a low setpoint may never reach the state that causes the fault. And log at least two independent readings on a fixed interval, every 10 minutes is plenty, so you can see a trend rather than a single pass or fail.
Step 5: Instrument a component temperature, not just the outcome
The symptom is the last thing to change. Watching only the symptom means you learn nothing until the system quits.
Pick the component your suspected mechanism would heat: a connection, a motor housing, an enclosure, a bearing, a control device. Take a surface temperature at minute 5 and then on the same interval as everything else. A runtime fault shows a component climbing toward, and then past, a plateau while ambient conditions hold flat. That single divergence, a part getting hotter while the surroundings do not, is the cleanest evidence you can hand a customer.
Skip this step and you can still get a right answer, but you will be guessing at which component, and you will have nothing to show for the diagnosis except a system that quit on schedule.
Step 6: Check whether the axis is starts rather than hours
Not everything that looks like run time is run time. Some faults track the count of starts and stops, and a continuous test hides them completely, because a two hour continuous run contains exactly one start.
Suspect the start axis when the complaint includes short-cycling, when the failures cluster at times of day with light load, or when the customer describes it quitting "right after it kicks on" rather than mid-run. Test it by cycling the system deliberately, four to six starts with realistic off time between them, and watching whether each start is weaker or slower than the last.
Step 7: Decide what the answer changes
Land the separation on a repair path, not on a label.
| Finding | What it points at | What you would do next |
|---|---|---|
| Tight run time, scattered condition | Accumulation or heat rise inside the system | Find the component that heats or the path that fills |
| Scattered run time, tight condition | The system is exposed to something external | Look at placement, protection, supply quality, sizing against extremes |
| Run time shrinks as condition worsens | Accumulation with the condition setting the baseline | Fix the accumulation, then verify against the worst condition |
| Tight start count, no run-time pattern | Start components, controls, or cycling behavior | Test starts, not hours |
If you cannot place a case in one of those four rows, you do not yet have enough occurrences. Go get two more rather than picking the closest-looking row.
The worked example, carried through
A booster pump on a small commercial supply trips its overload protector. The customer's opening line is that it happens on hot days.
Six occurrences got logged with both clocks. Run times at failure came out as 38, 44, 41, 52, 40 and 47 minutes. That is a total of 262 minutes across 6 events, an average near 44 minutes, with a spread of 14 minutes from the shortest to the longest. Fourteen minutes on a 44 minute mean is roughly a third, which for numbers a customer produced from memory is tight clustering.
The condition column was the opposite. Two events happened on genuinely hot afternoons, three happened on mild mornings, and one happened on an overcast day that never got warm. Ambient spread across the six was well over 20 degrees F. No threshold, no clustering, no pattern.
Tight run time, scattered condition, row one of the table. The cold-start question came back a firm no: it had never quit in the first ten minutes, not once, not on the hottest day of the summer.
The confirming test ran on a mild morning. Target duration was 1.5 times 44 minutes, so 66 minutes, with surface temperatures logged every 10 minutes at the motor housing, the protector, and the supply connections. Ambient held flat within a couple of degrees for the whole run. The motor housing rose and plateaued, which is normal. One supply connection did not plateau. It kept climbing after the housing settled, and it was visibly the hottest point on the assembly by minute 40. The protector opened at minute 46, a fair match for the logged average of 44.
Confirmed cause: a high-resistance connection heating under sustained current, dumping enough extra heat into the protector to open it early. Nothing to do with weather. The hot-day events were just the two occasions the customer happened to notice and remember, which is exactly how a runtime fault gets misfiled as a weather fault.
Verification after the repair reran the same 66 minute test in the same mode. The connection tracked the housing and plateaued with it, and the protector held. One more run past 90 minutes on the next warm day closed it out.
What doing this wrong looks like
The classic wrong turn is accepting the customer's causal theory as a data point. They said hot days, so the ticket says hot days, so the tech tests on a hot day, sees a hot machine, and recommends something about heat rejection or shading. It sometimes even helps for a while, because reducing the baseline temperature buys a few extra minutes before an accumulating fault crosses the line. Then it comes back and now the customer has paid for a change that did not address the mechanism.
The second wrong turn is testing on the right day and treating a single failure as confirmation. If you run long on a hot afternoon and it quits, you learned nothing about which clock caused it, because both clocks were running. Only the deliberately mild-day long run separates them.
Catch both by insisting on the occurrence table before any repair recommendation. If the table has fewer than four rows, or if one of the two columns is empty, you are not separating anything yet.
How to verify you got the separation right
Predict, then check. A correct separation lets you state in advance what the system will do: "on a mild day this will still quit near 45 minutes" or "on a mild day this will run all afternoon." Being able to make that call before the run, and being right, is the proof. Being surprised means the mechanism is not what you named.
After the repair, re-run the test that originally reproduced the fault, at the same duration and in the same mode, and hold past the previous failure point by a comfortable margin. Then get one customer-observed confirmation under the worst condition they normally see. Two clean results on two different clocks is a closed case.
References
- Manufacturer documentation on continuous-duty ratings, service factors, and thermal protection behavior
- Trade-standard practice for intermittent-fault investigation and occurrence logging
- See related: Why a Short Test Cycle Passes a Failing System
- See related: The Fault That Only Shows in Heat, Cold, Humidity, or Storm
- See related: Correlating a Fault With the Customer's Own Routine