faults, errors, and failures
These three words are often used loosely, but reliability engineers keep them sharply separate, and the distinction is genuinely useful. Picture a tiny crack forming in a bridge cable (a fault). It may sit there harmlessly for years. One day under heavy load a strand actually snaps (an error — the system is now in a wrong internal state). If enough strands snap, the bridge can no longer carry traffic (a failure — the service users depend on is no longer delivered). A fault is a cause, an error is a wrong state, a failure is the visible loss of correct service.
In hardware: a fault is a defect or disturbance — a stuck transistor, a manufacturing flaw, or a cosmic ray striking a memory cell. A fault is only latent until something activates it. When the fault produces an actually-wrong value in a register, a cache line, or a memory word, the system holds an error: its internal state no longer matches what it should be. A failure occurs only if that error propagates all the way out to affect the service the user observes — a crash, a wrong answer returned, a frozen screen. The chain is fault leads to error leads to failure, and crucially each arrow can be broken.
Why obsess over the distinction? Because reliable design works by breaking the chain at each link. You can prevent faults (better manufacturing, shielding), tolerate errors so they never become failures (error-correcting codes that silently fix a flipped bit, redundancy that votes out a wrong copy), or contain failures so they stay local (isolation, graceful degradation). A flipped bit (a fault that became an error) need never reach the user if an ECC catches and corrects it (see error-correcting-code). Most of architecture security and reliability is the art of stopping a fault before it ever surfaces as a failure.
A cosmic ray flips a bit in a DRAM cell (a fault). When the CPU reads that word, it loads the wrong value (an error). If the memory has ECC, the code detects and corrects the flip, so the program never sees anything wrong — the chain is broken at the error stage, and no failure occurs. Without ECC, the wrong value might crash the program or corrupt a file (a failure).
Fault to error to failure — ECC breaks the chain in the middle, so a flipped bit never becomes a visible failure.
Not every fault becomes a failure, and that gap is the whole game. Treating the three as synonyms hides exactly the places — error detection and correction — where reliability is actually won.