Is This Fault Worth a Stakeout Visit, Decision Tree

Why this matters

Some faults refuse to show up on demand. You arrive, everything tests fine, and the customer swears it happens "all the time." One option is a stakeout visit: schedule a longer block, or return at the specific time or condition the fault tends to appear, and wait for it to happen with you standing there. That's a real, sometimes necessary tool, but it also ties up a technician's time on one job for a chance, not a certainty, of catching the fault live. This tree is for deciding when a stakeout visit is worth committing to versus when a different approach gets you there faster.

Start here: is there a specific, predictable trigger

If the customer can identify a specific time, condition, or sequence that reliably precedes the fault (a certain time of day, a specific combination of equipment running, a particular weather condition), a stakeout timed to that trigger has a real chance of success and is worth considering. Move to the next check.

If the fault is described as totally random with no identifiable pattern, a stakeout is a much weaker bet, because you have no way to time it for better odds than showing up and hoping. Consider a monitoring or logging approach instead (see below) before committing technician time to an unscheduled wait.

If a logging or remote-monitoring option exists

Before scheduling a technician to physically wait, check whether the fault can be captured without a body in the room. Many systems support some form of data logging, a recording thermostat, an event log on a control board, a simple portable data logger you can leave in place, or a request that the customer record video the moment it happens on their phone. If a logging option exists and can be left running unattended, that's almost always a better first move than a stakeout, because it captures the fault whenever it actually occurs, without tying up a paid technician hour for hour on a guess.

If no logging option exists, or the fault is something a log wouldn't fully capture (a smell, an unusual sound, a specific mechanical behavior that needs a trained eye to interpret), a stakeout becomes more clearly worth it, because a technician's judgment is genuinely part of what you need captured, not just a number or a timestamp.

If the fault carries real risk if it happens unobserved

Weigh the consequence of the fault occurring without anyone watching. If an unwitnessed occurrence carries a real safety or damage risk (repeated tripping of a protective device that could eventually fail to protect, a fault that could escalate if it recurs unaddressed), that raises the case for a stakeout even against modest odds of catching it, because the value isn't only diagnostic, it's also having a trained person present if something serious happens.

If the fault is a nuisance or comfort issue with no meaningful risk from an unwitnessed occurrence, weigh the stakeout purely on diagnostic value and cost, without the added weight of a safety argument.

If the odds of catching it in a reasonable window are genuinely low

Be honest with the customer and yourself about probability. A fault that occurs once every few weeks, with no reliable trigger, is a poor candidate for even a several-hour stakeout, the odds of it happening in that specific window are low regardless of how patient the tech is. If the expected wait, based on how often the customer says it occurs, is much longer than a reasonable single visit, don't commit to an open-ended stakeout; instead pursue logging, ask the customer to trigger the suspected condition deliberately if that's possible, or accept that this fault may need to be diagnosed from indirect evidence rather than a live catch.

If the customer's account suggests the fault occurs frequently enough that a few hours has a real chance of catching it, a scheduled stakeout block becomes a much more reasonable investment.

If you can recreate the triggering condition instead of waiting for it

Often the better move than waiting for a fault to happen naturally is deliberately recreating the condition believed to trigger it, running the equipment through the specific sequence, load, or condition the customer describes, rather than waiting passively for it to occur on its own schedule. If you can safely and directly recreate the suspected trigger on demand, do that first; it turns an open-ended wait into a controlled, minutes-long test with a much higher success rate than passive waiting.

If the trigger genuinely can't be recreated on demand (it depends on outdoor conditions, a specific occupancy pattern, or something else outside your control), a stakeout timed to the natural occurrence of that condition is the remaining option.

Setting the visit up to actually succeed

Once you've decided a stakeout is worth it, set real conditions for success rather than just showing up and waiting. Bring whatever test equipment the suspected fault would call for already set up and ready, not packed away, so you're not scrambling to connect a meter in the ten seconds the fault is actually happening. Confirm with the customer exactly what triggers or precedes the fault as best they can describe it, and position yourself to observe that trigger, not just the equipment itself. Set a clear time box with the customer up front, so an unsuccessful stakeout has a defined end rather than dragging on indefinitely.

Recap

1. Check whether there's a specific, predictable trigger before committing to an open-ended wait.
2. Check for a logging or remote-monitoring option that captures the fault without tying up a technician.
3. Weigh whether an unwitnessed occurrence carries real safety or damage risk.
4. Be honest about the odds of catching an infrequent, untriggered fault in a reasonable window.
5. Try recreating the trigger directly before waiting for it to happen naturally.
6. When a stakeout is worth it, set it up with equipment ready, a known trigger to watch for, and a time box.

References

• Trade-standard practice for capturing intermittent faults (data logging, deliberate condition recreation)
• See related: Recreating the Conditions to Find the Fault; The Fault That Only Shows Up Under Full Load Decision Tree