Three Words We Use Interchangeably And Should Not

A fault, an error and a failure are different things, and confusing them muddles every incident discussion.

A fault is the defect itself, the mistaken piece of logic sitting quietly in the system, possibly for years, doing nothing at all until something reaches it. An error is what happens when execution actually reaches that fault and the internal state of the system becomes wrong. A failure is when that wrongness becomes visible outside the boundary: a customer sees an incorrect figure, a request is refused, a report goes out with the wrong total. The three are distinct, they are separated in time, and the gap between them is often long. Most faults never become errors. Many errors never become failures.

Keeping the words apart changes how you talk about incidents. A team that says a bug appeared on Tuesday is usually describing a failure that surfaced on Tuesday from a fault introduced months earlier under quite different conditions. Once you separate the three, useful questions become askable. How long did the fault sit undetected? What changed to make execution reach it? Why did the error propagate all the way to a failure rather than being caught at some boundary along the way? Each question points at a different improvement, and lumping them together as one bug hides all three.

This is not vocabulary for its own sake. The distinction tells you where to invest. If faults are being introduced faster than they are found, the problem is in how work is written and reviewed. If faults sit for a long time before anything reaches them, the problem is coverage of unusual paths. If errors reliably become failures because nothing stops them travelling, the problem is the absence of boundaries that check their assumptions. Three different problems with three different remedies, all invisible while the team has only one word for the lot.