← Research
Research

What is silent failure?

The output arrives, it reads normally, and nothing marks the point where it stopped being right.

Last reviewed: 17 September 2026

The definition and where it comes from, why gray failure in 2017 and silent data corruption in 2021 are the same problem one layer down, what an agent does when a tool fails without saying so, and why the only detector that reliably fired was a person who knew what the output should have looked like.

Questions this page answersAll 811 questions this research covers

A silent failure is a failure that tells nobody. The job runs, the answer comes back, the page renders, and somewhere inside that sequence something stopped being true without raising a hand. The term belongs to engineering rather than to anybody in particular, and predates by decades the systems that have made it fashionable. What has changed in the last two years is the part of the stack it now happens in, and what the failing component does with the silence.

The answer, in one line

Silent failure is a failure that produces no error signal a person can act on. The system carries on running, the output looks ordinary, and nothing marks the point at which it stopped being right.

Share as a card

Definition#

Silent failure: a failure that produces no error signal a person can act on. The system carries on, the output looks ordinary, and nothing marks the point at which it stopped being right. An established engineering term with no single owner, formalised for distributed systems by Huang and colleagues in 2017 under the name gray failure. Used here in that sense and not claimed by this research.

Share this definition as a card

Somebody noticed, and it was not the alarm#

The sharpest definition available comes from a 2017 paper by seven engineers at Microsoft Research and Microsoft Azure. They were trying to explain why cloud systems built entirely out of redundancy and failure detection kept going down anyway, and their answer was that the failures doing the damage were not the ones a detector is built to catch. Their name for these is gray failure, and their definition of it is a relationship rather than a symptom: a system experiences gray failure when at least one app makes the observation that system is unhealthy, but observer observes that system is healthy. They call the property differential observability.

That framing does the heavy lifting on this page, so it is worth being precise about its parts. There is the system. There is an observer inside the system whose job is to notice whether it is failing. And there is an app outside it, using the service and forming its own view from end to end. A gray failure is the gap between those two views. The person suffering the failure and the thing watching for failures disagree, and the one that gets believed is the one holding the alarm.

Huang and colleagues draw a counter-intuitive consequence out of this that has aged well. Adding redundancy can lower availability. If a request fans out across many components, the chance that it touches at least one degraded component climbs towards certainty, so more redundancy means more opportunities for a subtle fault to reach a user while every health check stays green. Their paper is a characterisation rather than a measurement, and they say so; the incidents are recounted from their own experience and no rates are published.

Four years later, seven engineers at Facebook published a fleet study of the same shape one layer down. Silent data corruption, in their account, is not captured by the error-reporting machinery inside a processor and so cannot be traced at the hardware level, while the bad data travels up through the stack and emerges as an application problem. They ran a library of silent-error tests across hundreds of thousands of machines over more than eighteen months and found hundreds of processors affected, which they read as a systemic property of manufacturing rather than a bad batch. Their conclusion is the part that transfers. Better hardware was half of the answer; the other half was software written on the assumption that the layer underneath it can be quietly wrong.

When the failing component writes fluent prose#

An agent system inherits all of that and adds something the 2017 model did not anticipate. In the cloud case the observer is blind. In the agent case the observer can be actively furnished with a story.

Wei Wu published an eight-week account in June 2026 of one personal-assistant agent runtime he operates: roughly forty scheduled jobs across eight model providers, guarded by 4,286 unit tests and 827 governance checks. Across twenty-two incidents with full postmortems, one pattern recurred at least twenty-eight times, and he defines it as a failure whose error signal never reaches a human in a form they can act on. His five-class taxonomy runs from platform quirks through design-assumption mismatches and error swallowing to what he calls chained hallucination and fabrication. He singles out that fourth class and gives it a name, fail-plausible, describing it as differential observability escalated, where the observer is not merely blind but is convincingly misled by the failure itself. The term is his.

Three of his numbers matter here and all three come with the same caveat, which is that this is one system, twenty-two incidents chosen by the person who runs it, and no control. About 70 per cent of the silent failures were caught by a human looking at the user-facing view rather than by the tests or the governance checks. A retrospective audit of fifteen incidents would have prevented none of them in advance and would have blocked 87 per cent from recurring, which he reads as audits being regression engines rather than prediction engines. And the time to detection ran from thirteen hours to sixty days, tracking the failure mechanism rather than code complexity, with the longest-lived faults sitting in the seams between components where no test runs.

The measurement, and what it caught the models doing#

Two months later, in August 2026, four researchers put a number on the mechanism. Their starting observation is mundane and load-bearing: an agent calling a production interface cannot distinguish a query that matched nothing from a query the server did not understand, because both come back with a success code and a readable body. There is no exception to catch and no field to branch on.

They audited 721,320 parameters across 2,501 independently published interface documents and found that 7.5 per cent declare a fixed vocabulary and 15.2 per cent declare any machine-checkable constraint at all, while 40.1 per cent state at least one rule in prose that the machine-readable schema never encodes. They then fired 219 deliberately malformed calls at live commercial endpoints from twenty-seven vendors. The predictor of whether the failure announced itself was the form of the constraint rather than the identity of the vendor: machine-checkable constraints returned an honest error in 111 of 111 cases, and prose-only constraints failed silently in 44 of 61.

Then they ran twelve models across eight families on ordinary tasks against those endpoints. A vocabulary that the documentation merely gave examples of was missed by every model on 88 of 88 attempts. Written out in full, it was used correctly 88 to 91 per cent of the time. And running the full loop on the resulting failures, the models detected the silent failure in 12 per cent of cases, repaired it in 0 per cent, told the user there was nothing there in 41 per cent, and invented a figure in 12 per cent.

Read those four figures together and the shape of the risk is clear enough. In slightly more than half the cases the person on the other end was told something untrue, and in a quarter of those the untruth was a number. Promoting the vocabulary into the machine-readable schema removed the failure entirely, from 88 of 88 to 0 of 89, so the fault was in how the interface declared itself and not in the quality of the models. That is a preprint, one perturbation set and one intermediary layer, and none of it has been replicated.

The return flight that was never booked#

The cleanest illustration of what this looks like from the outside is one Rahim Hirji used in The Agents Are Here on 15 February 2026. An agent planned a three-day trip to Tokyo, in his words flights, hotels, concert tickets, local transport, and forgot to book the journey home.

Nothing in that itinerary looks wrong. It is complete, formatted, plausible and internally consistent, and there is no line in it reading return leg unresolved. The only thing capable of detecting the fault is a reader who already knows that a trip has two directions, and who is reading the itinerary against that expectation rather than against itself. That is the whole of the problem in one example. The engineers chose the word observer carefully: detection is a property of whoever is looking rather than of the thing being looked at.

His own reading of the episode runs the other way, and it belongs here because it is the honest counterweight. The agent still saved four hours, and as he puts it, we hold agents to a standard of perfection we've never applied to ourselves. Human travel agents also forget return flights. The estate's position is not that silent failure is a reason to stop; it is that silent failure moves the cost from the doing to the checking, and the checking is the part nobody has staffed.

Who is the observer now#

Huang's model has three roles: the system, the observer inside it, and the app outside forming its own view. In an agent deployment the app is usually a person. The whole architecture of detection therefore rests on a human being able to form an independent end-to-end view of whether the output is healthy, and that ability is a capability rather than a configuration.

This is where a system property becomes a workforce question. A silent failure is detectable only by someone who knows what the right answer looks like well enough to notice its absence, and the same deployment that introduced the silent failure is often the one that removed the practice by which people came to know that. An organisation can hold a complete audit trail, a governance framework and a monitoring dashboard, and still have nobody left in the app position. Wu's 70 per cent is a single data point and it says the same thing: the detector that fired was a person reading the output, not the 4,286 tests.

So the useful question for a board is not how many checks are in place. It is who, by name, would notice this output was wrong, what they would be comparing it against, and whether they still do enough of the work unaided to hold that comparison in their head. That is the invisible work of oversight, and silent failure is the failure mode that makes it non-optional.

Four papers is a thin base for a category this large#

Nothing above measures a human. Li and colleagues tested what models do with a silent failure and never tested whether a person catches it, so the estate's central claim on this page, that detection depends on the reader's capability, rests on the structure of the problem and on one operator's account rather than on a controlled result. Nobody has run the obvious experiment: give matched groups the same silently wrong agent output and vary how recently they did the work themselves.

Two of the three AI-era sources are preprints and one is a single author reporting on a system he built, maintains and publishes the remedy for. A frequency for silent failure in commercial deployments does not exist. Two figures circulate widely alongside this term, one attributed to MIT on the share of machine-learning models that degrade and one to Gartner on the share that degrade within twelve months, and neither is used here, because neither could be traced to a published method. A further 2026 preprint proposing an entropy principle for silent failure in agent systems could not be opened from either fetcher and is not cited.

Key sources

The work of catching this is described at the invisible work of oversight, and the reason it goes unpaid at the verifier's discount. On the fabrication half, what is an AI hallucination and why AI sounds so confident when it is wrong. On the person who is meant to be watching, automation bias, the vigilance decrement and the moral crumple zone. On the record that makes reconstruction possible at all, decision provenance. On what an agent acting alone changes, should I let an AI agent act on my behalf.

Explainer · SS-2026-265 · Graded against the published rubric

Cite this page

Hirji, R. (2026). What is silent failure?. The SuperSkills evidence base, SS-2026-265. https://thesuperskills.com/research/what-is-silent-failure. Last reviewed 17 September 2026.

An evidence review by Rahim Hirji, not peer-reviewed research. For a material claim, cite the underlying study as well; every study here carries its own permanent link.

How citations and IDs work
Questions answered on this page

What is silent failure?

Silent failure is a failure that produces no error signal a person can act on. The system carries on running, the output looks ordinary, and nothing marks the point at which it stopped being right. The term has no single owner and long predates AI; the nearest formal definition is Huang and colleagues' gray failure of 2017, which they define as differential observability, meaning that an application observes the system to be unhealthy while the component watching for failure observes it to be healthy.

Is silent failure the same as an AI hallucination?

They overlap without matching. A hallucination is a fabricated output. A silent failure is a failure that announces nothing, which a hallucination may then fill in. Li and colleagues measured the join in August 2026: when a tool returned an empty result because the call was malformed, models running the full agent loop detected the problem in 12 per cent of cases, repaired it in none, told the user there was nothing there in 41 per cent, and invented a figure in 12 per cent. The silence came first and the fabrication came second.

What is fail-plausible?

Fail-plausible is Wei Wu's term, from an eight-week study of one production agent runtime published in June 2026, for the class of silent failure in which a language model turns an error into fluent narrative and delivers it to the user. He describes it as gray failure's differential observability escalated, with the observer misled by the failure rather than merely blind to it. The term is his and is not claimed by this research.

How do you detect a silent failure?

In the one production account published so far, not by the machinery. Wu reports that about 70 per cent of the silent failures in his own runtime were caught by a human looking at the user-facing view rather than by its 4,286 unit tests or its 827 governance checks, and that a retrospective audit of 15 incidents would have prevented none of them in advance while blocking 87 per cent from recurring. That is one system and 22 incidents, so it is a direction rather than a rate. The direction points at a person who knows what the output should have looked like.

Is silent failure a new term?

No. It is ordinary engineering vocabulary with decades behind it. Silent data corruption was the subject of a Facebook fleet study in 2021, gray failure was defined at a systems workshop in 2017, and both describe the same shape: a component fails in a way the layer responsible for noticing does not see. Nothing about it originates with AI, and this research makes no claim on the phrase.

In this hub

Definitions

The terms this field uses, defined against their primary sources.

Ask the evidence
What does the evidence actually show?What should our board be asking about this?Where does Rahim disagree with the consensus?
Bring this into your organisation

If this describes something happening in your teams, say so.

Keynotes, board sessions and advisory work, drawing on research across more than 200 organisations in 30 countries. Tell me the room, the date and the shift you need. A reply within 24 hours.

Start a conversation

Topics and audiences  ·  All research

Box of Amazing

Rahim’s free weekly letter on AI and human capability

If this was useful, the weekly letter is where the thinking happens first. Most of what ends up on this site starts there. Weekly essays on AI, capability and the future of work. Read by 25,000 people, every week since 2017. Free, and one click to stop.

Opens Substack to confirm. No pitch in it, unsubscribe in one click, and nobody follows up because you read something.

Running an event, or responsible for how AI arrives in your organisation? Keynotes  ·  Advisory for CEOs and boards  ·  Enquire