The Fault That Returns After a Week: A Decision Tree
Why this matters
A fault that comes back a week after you "fixed" it is the most expensive kind. You ate the first visit, you're eating this one, and the customer's trust is dropping with each return. The recurrence is also a gift: it's proof you treated a symptom instead of the cause. The delay before it returns is itself a clue, because it tells you something accumulates, cycles, or drifts over days. This tree turns a frustrating callback into a structured hunt for the cause you missed the first time.
Start here: what does "a week" tell you?
A fault that returns on a delay is almost never random. Something builds up or shifts over time until it crosses a threshold again. Before you re-diagnose, ask what changes over the span of about a week.
- Accumulation: something fills, clogs, drains, or coats over days. A reservoir fills, a filter loads, a buildup forms, a slow leak empties a charge.
- Cycling: a counter or a duty cycle. The fault returns after so many runs, starts, or hours, not so many days.
- Environmental drift: it tracks weather, temperature swings, day/night cycling, or usage patterns that repeat weekly.
- A consumable or correction running out: whatever you topped up, reset, or cleaned is being used up again at a steady rate.
The recurrence interval points straight at the mechanism. Use it to aim.
Branch 1: Did the first fix treat a victim, not a cause?
The most common reason a fault returns is that you replaced or reset the part that failed without finding what stressed it. The replacement is now failing the same way for the same reason.
- A protective device tripped, you reset it, and the overload that tripped it is slowly building again.
- You replaced a worn or burned part, but the friction, restriction, or electrical stress that wore it is still there.
- You cleared a blockage but didn't fix what produces the debris.
- You topped off a fluid or charge but didn't fix the leak.
Ask: what made the original part fail? If you can't answer, that unanswered question is your fault, and it's refilling, reloading, or restressing right now.
Branch 2: Is it an intermittent that just hadn't recurred yet?
Sometimes the first fix did nothing, and the fault simply wasn't active when you tested. A loose connection, a marginal component that fails only hot or only under specific load, a wire chafing toward a short. It read fine, you found nothing, you swapped something to "do something," and the real intermittent surfaced again a week later when conditions lined up.
For these, the recurrence is your chance to catch it in the act. Try to be there, or set the system up, under the conditions present when it fails. Wiggle-test suspect connections (only after confirming it's safe to touch, see the energized-work rules). Run it to temperature and load. The fault that hides at idle shows itself under the real working condition.
Branch 3: Is something external resetting the clock?
Occasionally the recurrence isn't the equipment at all. A weekly cleaning, a scheduled cycle, a usage spike, or another trade's work resets the conditions and re-triggers a fault that was always latent. Ask the customer what happens on roughly the same cadence as the recurrence. The cause may be a behavior or a schedule, not a part.
Decision summary
| Clue | Likely mechanism | Where to look |
|---|---|---|
| Returns after consistent days | Accumulation or slow loss | Find what fills/empties/coats over that span |
| Returns after so many runs | Cycle or duty-count threshold | Tie it to starts/hours, not calendar |
| Tracks weather or time of day | Environmental drift | Reproduce under that condition |
| Same part failing again | Victim, not cause | Find the upstream stressor |
| Found nothing first visit | Unreproduced intermittent | Catch it under real working conditions |
| Matches a weekly activity | External trigger | Ask what recurs on that cadence |
The discipline: close the loop with a real cause
A recurring fault is not closed until you can name the mechanism and explain why your fix stops it from refilling, recycling, or re-stressing. Before you leave this time, run the system through the failure case, not an idle test, and confirm the condition that returns it can no longer build. If the best you've got is another reset or another swap with no named cause, you're scheduling the next callback. Treat the recurrence as the evidence it is, and chase it to the root.
References
- Trade-standard troubleshooting methodology (observe, isolate, test, verify).
- Manufacturer service documentation and diagnostic flowcharts (generic).
- OSHA safe-work practices for energized and pressurized equipment.
- See related: The Too-Simple and Too-Complex Trap; The Diagnosis That Doesn't Add Up Decision Tree.