The Repair LibraryRead · Learn · Master

Why Intermittents Are the Hardest Faults

Every method in this volume so far has leaned on one quiet assumption: the fault is present while you look for it. A dead rail stays dead for the meter, a distorted signal holds its shape for the scope, and a short keeps heating for the thermal camera. The intermittent fault breaks that assumption — the device that crashes twice a week, the audio that cuts out only in a cold room, the board that fails in the field and passes every test on the bench. This opening section is about why these faults are the hardest problem in repair, and about the two ideas that make them tractable. The difficulty is not exotic mechanisms: an intermittent is usually an ordinary fault — a cracked solder joint, a marginal component, a connection at the edge of contact — that has not finished failing, so it fails only when some condition pushes it over the line. The difficulty is evidence: diagnosis runs on observation, and an absent fault produces nothing to observe, which is how devices earn the miserable verdict of no fault found and go home to fail again. Worse, the bench itself changes the conditions — different power, different temperature, different position, a probe's touch — so the very act of examining the patient can hide the disease. The way out is to stop hunting the fault and start hunting its conditions: mining the fault history for the failure window — when, where, and under what circumstances the fault appears — and then converting that window into a reproduction recipe, a documented sequence that summons the fault on demand. Once a fault can be summoned, it is no longer intermittent in any way that matters: it is a steady fault that happens to need a ritual first, every tool in this volume applies again, and — just as important — the repair can be proven, because a fix is verified only when the recipe that once summoned the fault reliably fails to. By the end of this section you can classify an intermittent by what provokes it, explain why it hides at the bench, write its failure window from the history, and draft the recipe the rest of this chapter will teach you to execute.

IntermediateLow Risk20 min read

What You Will Learn

  • You will learn to classify an intermittent fault by what provokes it — mechanical, thermal, power and load, or time and environment.
  • You will learn to explain why intermittents defeat bench diagnosis, including how the bench itself changes the conditions.
  • You will learn to mine the fault history into a failure window — the conditions under which the fault appears.
  • You will learn to convert a failure window into a draft reproduction recipe with a precondition, a provocation, and an observable.
  • You will learn to treat reproduction as the gate for both diagnosis and repair verification, and 'no fault found' as a verdict on the method.

What You Will Be Able To Do

  • You will be able to classify an intermittent fault by what provokes it — mechanical, thermal, power and load, or time and environment.
  • You will be able to explain why intermittents defeat bench diagnosis, including how the bench itself changes the conditions.
  • You will be able to mine the fault history into a failure window — the conditions under which the fault appears.
  • You will be able to convert a failure window into a draft reproduction recipe with a precondition, a provocation, and an observable.
  • You will be able to treat reproduction as the gate for both diagnosis and repair verification, and 'no fault found' as a verdict on the method.

Required Tools

  • A notebook or worksheet for fault histories, failure windows, and recipes
  • A device with a known or reported intermittent fault to study
  • The owner or user of the faulty device, or their written complaint
  • Service records or prior repair notes where they exist
  • A thermometer or environment notes for correlating conditions

Section Overview

The methods of this volume assume the fault performs while you watch; the intermittent does not, and this section is about why that makes it the hardest problem in repair — and what makes it tractable (diagnosing-with-the-oscilloscope). An intermittent is an unfinished failure. Behind almost every intermittent is an ordinary mechanism — a cracked joint, a marginal component, a connection at the edge of contact — that fails only when some condition pushes it over the line, so intermittents are classified by their provocation: mechanical, thermal, power and load, or time and environment. The bench hides the disease. Diagnosis needs evidence and an absent fault produces none — and the bench changes the very conditions that provoke the fault, which is how devices earn the verdict of no fault found and go home to fail again. The fault history holds the way in. The failure window — when, where, and under what circumstances the fault appears — is mined from the user's account and the service record, turning anecdote into conditions (gathering-symptoms-and-fault-history). The window becomes a recipe. A reproduction recipe — a precondition, a provocation, and an observable — converts the window into a sequence that summons the fault on demand, and a summoned fault is a steady fault with a ritual in front of it. And reproduction gates everything after. A fault that cannot be summoned cannot be located with confidence, and a repair is proven only when the recipe that once summoned the fault reliably fails to (capturing-transients-and-single-shot-events). Classify the provocation, respect the hiding, mine the window, draft the recipe — and the fault that only happens sometimes becomes a matter of method.

Why This Matters

Intermittents fill a repair bench's saddest shelf: the devices that came back, the ones sent home with no fault found, the boards reworked twice for the same complaint (gathering-symptoms-and-fault-history). This matters because the intermittent is common, not rare: cracked joints, tired connectors, and drifting components are among the most frequent failures in aging electronics, and every one of them passes through an intermittent phase before it fails outright. This matters because the naive strategy wastes the bench: powering a device and waiting for a twice-a-week fault burns days and proves nothing, while a mined failure window can compress the same hunt into an afternoon. It matters because no fault found is expensive twice: once in the unsolved fault that returns, and again in the trust lost when a customer's real problem is answered with a shrug — when the honest reading of that verdict is that the bench did not reproduce the conditions (diagnosing-with-the-oscilloscope). It matters because repairs of unreproduced faults cannot be verified: replacing a suspect part without a recipe leaves no way to tell a fix from a coincidence, which is how the same board gets repaired three times (capturing-transients-and-single-shot-events). And it matters because the campaign works: provocation, standing watches, and disciplined documentation — the tools of this chapter — turn most intermittents into reproducible, diagnosable, provable repairs (freeze-spray-and-localized-heat-for-isolation). Learn why the fault hides, and the rest of the chapter teaches how to drag it into the open.

Required Prerequisites

  • Gathering Symptoms and Fault History — Section 1.3 taught symptom collection and the fault history; this section turns that history into the failure window an intermittent demands.
  • Diagnosing with the Oscilloscope — Section 8.6 assembled the scope method that intermittents resist; this section explains the resistance and sets up the chapter that overcomes it.
  • A notebook or a structured worksheet — to record histories, failure windows, and draft recipes (gathering-symptoms-and-fault-history)
  • A written complaint or interview notes from the device's user — to mine for the conditions the bench must recreate
  • Prior repair records for the device or its model — to spot the repeat offender patterns that mark an intermittent
  • A log sheet or label for the device under test — to track what has been tried, provoked, and observed across sessions
  • Environment notes — room temperature, humidity, time of day — to correlate conditions with appearances of the fault
  • A device with a reported intermittent fault — to practise history mining and window writing on a real case (gathering-symptoms-and-fault-history)
  • A board with a known cracked joint or tired connector — to see a mechanical intermittent respond to gentle handling
  • A device that misbehaves warm or cold — to observe a thermal failure window first-hand (freeze-spray-and-localized-heat-for-isolation)
  • A bench supply with adjustable voltage — to preview how supply margins expose power-window faults
  • A scope with persistence and single mode — to preview the standing watches the campaign will use (capturing-transients-and-single-shot-events)
  • A folder of past no-fault-found cases, if the bench keeps them — to re-read old defeats as failure-window exercises

Real-World Applications

Every bench accumulates intermittent war stories; the method is what separates the solved ones from the shelf. A technician handed a laptop that "just restarts sometimes" interviews the owner and learns it restarts during video calls on battery — a failure window naming load and power source before a probe ever lands (gathering-symptoms-and-fault-history). A repairer with an amplifier that cuts out "randomly" reads the history — always after an hour, always recovering after a rest — and classifies it thermal before choosing a single test (freeze-spray-and-localized-heat-for-isolation). Someone facing a game console returned twice as no fault found notices both bench sessions ran the console flat on a table while the owner racks it vertically — the bench had been quietly removing the mechanical condition. A shop triaging a car stereo that drops out on rough roads writes the recipe draft in one line — powered, playing, flex the harness — and reproduces the fault in minutes as a preview of mechanical provocation. And a bench closing a reproduced-and-repaired fault runs the recipe ten times against the fixed board and files the silent result as the proof (capturing-transients-and-single-shot-events). The failures this prevents: days of powered waiting for a twice-a-week fault, a no-fault-found verdict issued because the bench never recreated the conditions, and a "repaired" board returned because nobody could prove the fix fixed anything.

Common Challenges

  • The history arrives as anecdote, not data. Users report impressions — "it dies randomly," "it hates Mondays" — the difficulty is asking the questions that turn impressions into conditions: what was it doing, how long had it run, what changed just before (gathering-symptoms-and-fault-history).
  • The bench is a different world. Different supply, different temperature, different position, no user habits — the difficulty is noticing which condition the bench removed, because the fault's absence looks like health rather than like a missing ingredient.
  • Patience masquerades as method. Leaving a device running and glancing at it feels like work — the difficulty is that unwatched waiting produces no evidence when the fault does strike, so time is spent without instruments armed to catch anything (capturing-transients-and-single-shot-events).

Safety Notes

Risk Level: Low. This section is history-mining and classification — paperwork and observation rather than provocation — but it handles devices whose faults are by definition unpredictable.

Professional Tips Before Starting

  • Interview before you unscrew. The failure window usually lives in the user's memory, not on the board — ten minutes of questions can save days of waiting (gathering-symptoms-and-fault-history).
  • Ask what changed just before. Faults are provoked — by warmth, motion, load, or time — the moment before the fault is where the provocation hides.
  • Never file no fault found without a window. An unreproduced fault with an unexplored window is an unfinished job — record what conditions were and were not recreated.

The Intermittent Problem — Classes, Hiding, Windows, and Recipes

Recap and Frame

Volume 5 has built a diagnostic method — route, ritual, signature, capture — and every piece of it assumes a fault that holds still to be measured; this chapter begins where that assumption fails (diagnosing-with-the-oscilloscope). The intermittent breaks the evidence chain. Diagnosis is comparison against expectation, and a fault that is absent during the comparison produces a healthy trace, a clean reading, and a false acquittal. The mechanisms are ordinary. An intermittent is rarely an exotic fault — it is a crack, a drift, or a marginal contact that has not finished failing, which means everything this volume taught still applies once the fault can be made to appear. The strategy therefore inverts. Instead of hunting the fault, the campaign hunts the fault's conditions — the circumstances that push the unfinished failure over the line — because conditions can be recreated on schedule while the fault cannot (gathering-symptoms-and-fault-history). Two ideas carry the chapter. The failure window names the conditions under which the fault appears, and the reproduction recipe converts the window into a repeatable summons — precondition, provocation, observable. And the capture skills stand ready. When reproduction takes time rather than technique, the standing watches of the last chapter — persistence, tripwires, logged instruments — do the waiting with the evidence armed (capturing-transients-and-single-shot-events). Hold the frame — ordinary mechanisms, inverted strategy, window then recipe — and the hardest faults in repair become a campaign rather than a vigil.

The Classes — What Provokes an Intermittent

Intermittents are classified not by symptom but by provocation, because the provocation is what the bench will have to recreate (freeze-spray-and-localized-heat-for-isolation). Mechanical faults answer to motion. Cracked solder joints, fractured pads, worn connectors, and broken wire strands make and lose contact with flex, pressure, vibration, and orientation — the fault that follows handling, transport, or a thump is announcing its class. Thermal faults answer to temperature. Expansion opens hairline cracks, semiconductors drift with heat, and marginal parts fail warm or fail cold, so the fault that needs a warm-up, hates a cold morning, or recovers after a rest is thermal — and the freeze-spray and heat techniques already met in thermal diagnostics become its provocation tools. Power and load faults answer to demand. Supplies at the edge of regulation, tired capacitors, and marginal drivers fail when load steps, voltage sags, or the demanding function runs — the crash that only happens during the heavy task names its own trigger (diagnosing-with-the-oscilloscope). Time and environment faults answer to circumstance. Humidity, dust, leakage across contamination, and slow drift produce faults tied to weather, season, location, or sheer hours of operation — the class that most needs the long watch, because its provocation is hardest to compress. Classes overlap and combine. A cracked joint may need both warmth and flex; a marginal supply may fail only loaded and hot — so the class is a starting hypothesis for provocation, not a verdict. Motion, temperature, demand, circumstance — alone or combined — and the intermittent's class points the campaign at its provocation. Name what provokes the fault, and you have named the experiment that will summon it.

The Hiding — Why the Bench Sees a Healthy Device

The intermittent's defining cruelty is that it hides precisely where the tools are, and the hiding has mechanics worth understanding (gathering-symptoms-and-fault-history). An absent fault produces no evidence. Every method in this volume observes the fault in action — a wrong voltage, a sick waveform, a hot spot — so a fault that is not acting produces the signature of health, and honest instruments report a working device. The bench removes conditions without noticing. The bench supply is stiffer than the wall adapter, the open board runs cooler than the closed case, the device lies flat instead of standing racked, and nobody runs it for three hours the way its owner does — each difference quietly removes a candidate provocation. The examination disturbs the patient. Opening the case flexes the board, reseating a connector wipes its contacts, and a probe's touch adds load and a ground path — any of which can temporarily heal a marginal fault, which is why a device that arrives faulty and measures healthy has often been accidentally repaired for a week (diagnosing-with-the-oscilloscope). Absence gets misread as innocence. A clean bench session invites the conclusion that nothing is wrong, when the correct conclusion is that nothing was reproduced — the difference between acquitting the device and acquitting the test. And the misreading has a name. No fault found is the verdict that sends the device home to fail again, and read honestly it is a verdict on the method: the failure window was not recreated at the bench. No evidence from an absent fault, conditions removed unnoticed, the patient disturbed by the examination, and absence misread as innocence — that is how the intermittent hides. Treat a clean session as an unreproduced window, not a healthy device, and the hiding loses its power.

The Window — Mining the History for Conditions

The way into an intermittent is not through the board but through the story, and the skill is turning anecdote into conditions (gathering-symptoms-and-fault-history). The window has three questions. When does it happen — after warm-up, on cold mornings, during the heavy task; what is happening — which function, which load, which position; and what changed just before — the moment preceding the fault is where the provocation hides. Users know more than they think. "It dies randomly" almost never survives good questions — asked what it was doing each time, owners recall the video call, the third hour, the bumpy road — so the interview is conducted as evidence collection, with the answers written down verbatim. Patterns accumulate across incidents. One failure is an anecdote; five failures with times, tasks, and conditions are a dataset, and the conditions that recur across incidents are the window taking shape. The bench's own history counts. Sessions where the fault did not appear are data too — each one lists conditions that did not provoke the fault that time, evidence against their sufficiency that strengthens as quiet sessions accumulate or outlast the fault's typical interval, narrowing the window from the other side (capturing-transients-and-single-shot-events). The window is written, not remembered. A failure window is recorded as explicit conditions — powered thirty minutes, playing audio, case closed, room below 15 degrees C — because the next section of the campaign will try to recreate it item by item. When, what, and what changed, asked across incidents, narrowed by the quiet sessions, and written as explicit conditions — and the window is mined. Extract the failure window from the history, and the intermittent has an address.

The Recipe — From Window to Summons

A window describes where the fault lives; the recipe is the knock that brings it to the door (freeze-spray-and-localized-heat-for-isolation). A recipe has three parts. The precondition sets the state — warmed thirty minutes, running the heavy task, standing vertical; the provocation is the action — flex the corner, chill the suspect area, step the load; and the observable defines what counts — the reset, the dropout, the artifact on a watching scope. The observable is instrumented, not eyeballed. An observable trusted to human attention is lost when attention wanders, so the recipe names the instrument that will witness it — a tripwire trigger on the rail, persistence on the suspect line, a logged meter — armed before every attempt (capturing-transients-and-single-shot-events). The draft starts crude and sharpens. The first recipe recreates the whole window at once; once the fault appears, conditions are removed one at a time until the minimal recipe remains — and the shrinking itself localises the fault, because the conditions that survive point at the mechanism. A recipe that works changes the game. A summoned fault is a steady fault with a ritual in front of it: the route, the ritual, the signature, and the capture ladder of the last chapter all apply again, run inside the recipe's window (diagnosing-with-the-oscilloscope). A recipe that fails is a result. A window recreated faithfully with no fault narrows the window, moves suspicion to an unrecorded condition, and earns another round of history mining — documented either way. Precondition, provocation, and an instrumented observable, drafted whole, shrunk to minimal, opening the door to every steady-fault method — and the recipe is the campaign's first weapon. Convert the window into a recipe, and the fault stops choosing when to appear.

The Gate — Reproduction as Proof

The recipe earns its keep twice: once finding the fault, and again proving the repair — and the second use is the one benches skip at their peril (diagnosing-with-the-oscilloscope). An unreproduced fault makes an unprovable repair. Replacing the plausible suspect without a recipe leaves no test that distinguishes a fix from a coincidence, and the intermittent's own rarity will happily impersonate a cure for a week. Reproduce before repairing whenever the fault allows. The discipline is to hold the repair until the fault has been summoned and its mechanism confirmed — resisting the temptation to resolder everything plausible and hope, which sometimes works and never teaches. Verification is the recipe run against the fix. After the repair, the same recipe runs again — same precondition, same provocation, same instrumented observable — and the fault's failure to appear across repeated runs is the proof (capturing-transients-and-single-shot-events). The proof has honest limits. A recipe that summoned the fault two times in three proves a repair only statistically, so the verification runs enough repetitions to beat the fault's own unreliability, and the count is recorded rather than guessed. Some faults never reproduce. When the campaign fails — window explored, recipes exhausted — the honest outcomes are a documented no-fault-found with the explored conditions listed, or a justified preventive repair of the most probable mechanism, labelled as such rather than passed off as a diagnosis. Unprovable repairs without reproduction, reproduction before repair, verification by the recipe's silence, honest statistics, and honest failure — reproduction gates the whole campaign. Prove the repair with the same recipe that proved the fault, and the device stops coming back.

Common Mistakes

  • Waiting for the fault instead of hunting its conditions. A twice-a-week fault outlasts any watch that is just waiting — mine the history for the window and recreate conditions instead (gathering-symptoms-and-fault-history).
  • Reading a clean bench session as a healthy device. Absence of evidence is an unreproduced window, not innocence — list which conditions the bench did and did not recreate before concluding anything.
  • Letting the bench remove the provocation. Stiff supply, open case, flat position, short sessions — audit the differences between the bench and the fault's home before trusting a quiet device.
  • Provoking without an instrumented observable. A fault that appears unwitnessed teaches nothing — arm the tripwire, the persistence watch, or the logger before every provocation (capturing-transients-and-single-shot-events).
  • Repairing before reproducing. A part swapped on plausibility cannot be verified, and rarity impersonates a cure — summon the fault first, and prove the fix by the recipe's silence.

Troubleshooting Guidance

The intermittent campaign starts with class, window, recipe, and gate. If the report is an intermittent: interview first — when it happens, what it was doing, what changed just before — and write the answers as conditions (gathering-symptoms-and-fault-history). If the fault follows handling, transport, or position: classify it mechanical and expect flex, tap, and orientation to be the provocation. If the fault needs warm-up or a cold morning, or recovers after a rest: classify it thermal — the freeze-spray and heat tools from thermal diagnostics will drive it (freeze-spray-and-localized-heat-for-isolation). If the fault rides the heavy task or the weak battery: classify it power and load, and plan supply-margin and load-step provocation. If it tracks weather, season, or sheer hours: classify it time and environment, and plan the long watch. If the device is quiet at the bench: audit what the bench changed — supply, temperature, position, duration — and restore the missing condition rather than extending the wait (diagnosing-with-the-oscilloscope). If a provocation is about to run: arm the observable first — tripwire, persistence, or logger — so an appearance cannot pass unwitnessed (capturing-transients-and-single-shot-events). If the fault has been reproduced and repaired: run the same recipe against the fix, enough times to beat the fault's own unreliability, and record the count. The throughline: classify by provocation, mine the window, draft the recipe, arm the witness, and let reproduction gate both the diagnosis and the proof.

Verification & Testing Methods

Confirm the groundwork before the campaign's tools come out:

  • [ ] I classified the intermittent by its provocation — mechanical, thermal, power and load, or time and environment — as a hypothesis from the history, not a guess from the symptom.
  • [ ] I can name the ways a bench hides an intermittent — removed conditions, the disturbed patient, absence misread as innocence — and audited this case's bench differences explicitly.
  • [ ] I mined the history into a written failure window — when it happens, what is happening, what changed just before — using quiet sessions to narrow it from the other side.
  • [ ] I drafted a reproduction recipe — precondition, provocation, and an instrumented observable — and planned to shrink it toward minimal once the fault first appears.
  • [ ] I treated reproduction as the gate: no repair before a summons where the fault allows, verification by the recipe's repeated silence afterward, and no fault found reserved for a documented, explored window — never for an unexamined one.

Then try the practice exercises below — history and recipe work; scenarios differ from the quiz.

Practice Exercises

  1. Mine a real history into a window (5 minutes, paper). Take a genuine intermittent complaint — from your bench, a friend, or a forum post — and extract a written failure window: when it happens, what is happening, what changed just before, and what the quiet sessions rule out (gathering-symptoms-and-fault-history).
  2. Classify a batch by provocation (5 minutes, paper). For five intermittent complaints — dies on bumps, needs warm-up, crashes in games, drops out in humid weather, restarts on battery — name each one's class, the provocation you would try, and the class it might combine with.
  3. Audit the bench against the field (5 minutes, bench). For a device on your bench, list every condition the bench changes from the fault's home — supply, temperature, position, enclosure, duration, user habits — and mark which ones its failure window names (diagnosing-with-the-oscilloscope).
  4. Draft and instrument a recipe, then plan its proof (5 minutes, paper). Convert your Exercise 1 window into a full reproduction recipe — precondition, provocation, observable — specify the instrument that witnesses the observable: which watch, on which node, armed how; then write the verification plan: how many silent runs of this recipe would prove a repair against the fault's own reproduction rate, and what a documented no-fault-found for this case would have to list (capturing-transients-and-single-shot-events).

These core steps — classifying the provocation, explaining the hiding, mining the window, drafting the recipe, and gating on reproduction — are tested in the Chapter Quiz at the end of this chapter, where a score of 80% is required to continue.

Key Takeaways

  • An intermittent is an ordinary fault that has not finished failing — a crack, a drift, a marginal contact — classified by its provocation: mechanical, thermal, power and load, or time and environment, alone or combined (freeze-spray-and-localized-heat-for-isolation).
  • Intermittents hide at the bench because an absent fault produces no evidence, the bench quietly removes conditions — stiffer supply, open case, flat position, short sessions — and the examination itself can heal a marginal fault for a week.
  • The way in is the failure window — when the fault happens, what is happening, and what changed just before — mined from the fault history across incidents and narrowed by the quiet sessions that build evidence against conditions' sufficiency (gathering-symptoms-and-fault-history).
  • The window becomes a reproduction recipe — precondition, provocation, and an instrumented observable — drafted whole, shrunk toward minimal, and a summoned fault is a steady fault: every method of this volume applies again inside the recipe's window.
  • Reproduction gates the campaign: no fault found is honestly issued only over a documented, explored window, and a repair is proven only when the recipe that once summoned the fault reliably fails to — run enough times to beat the fault's own unreliability (capturing-transients-and-single-shot-events).

Skills Learned

  • You can now classify an intermittent fault by what provokes it — mechanical, thermal, power and load, or time and environment.
  • You can now explain why intermittents defeat bench diagnosis, including how the bench itself changes the conditions.
  • You can now mine the fault history into a failure window — the conditions under which the fault appears.
  • You can now convert a failure window into a draft reproduction recipe with a precondition, a provocation, and an observable.
  • You can now treat reproduction as the gate for both diagnosis and repair verification, and 'no fault found' as a verdict on the method.

Glossary Additions

  • failure window — the set of conditions under which an intermittent fault appears: when it happens (after warm-up, on cold mornings, during the heavy task), what is happening (which function, which load, which position), and what changed just before the fault struck. The failure window is mined from the fault history — user interviews, service records, and the pattern across multiple incidents — and it is narrowed from the other side by quiet sessions, since every session where the fault did not appear lists conditions that did not provoke it that time — evidence against their sufficiency that strengthens as quiet sessions accumulate. Written as explicit, recreatable conditions rather than impressions, the failure window is the intermittent's address: it tells the bench what to recreate, and it is the raw material from which a reproduction recipe is drafted.
  • reproduction recipe — a documented sequence that summons an intermittent fault on demand, built from three parts: a precondition (the state to set up — warmed thirty minutes, running the demanding task, standing in its racked position), a provocation (the action that triggers — flex the corner, chill the suspect area, step the load), and an observable (what counts as the fault appearing, witnessed by an armed instrument such as a tripwire trigger, a persistence watch, or a logger rather than by human attention). A first recipe recreates the whole failure window; once the fault appears, conditions are removed one at a time toward the minimal recipe, and the conditions that survive point at the mechanism. A working recipe converts the intermittent into a steady fault with a ritual in front of it — and it becomes the repair's proof, verified when the same recipe, run repeatedly against the fixed device, reliably fails to summon the fault.
  • no fault found — the verdict issued when a reported fault cannot be observed or reproduced at the bench, and the most expensive words in repair when issued carelessly: the device goes home with its fault intact, fails again, and returns with the customer's trust reduced. Read honestly, no fault found is a verdict on the method rather than the device — it means the failure window was not recreated — so it is properly issued only after the window has been mined from the history and its conditions deliberately recreated, and it is documented with the list of conditions that were and were not reproduced. That record turns even a defeat into progress, because the next attempt starts where the last one stopped instead of repeating it.

Suggested Next Sections

Must read next:

Recommended: