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.
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.
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
- Huang, P., Guo, C., Zhou, L., Lorch, J. R., Dang, Y., Chintalapati, M. and Yao, R. (2017). Gray Failure: The Achilles' Heel of Cloud-Scale Systems. Proceedings of HotOS '17, Whistler, 8 to 10 May 2017, 6 pages. DOI 10.1145/3102980.3103005. The DOI resolves to the ACM Digital Library, which is gated; the authors' own copy is open and is the one read for this page, at Microsoft Research. Graded entry.
- Li, Z., Ye, S., Guo, F. and Dang, Z. (2026). SilentProbe: Measuring Silent Failure in Production APIs Used as Agent Tools. arXiv 2609.00035, 29 August 2026. Preprint, CC BY 4.0. Graded entry.
- Wu, W. (2026). When Errors Become Narratives: A Longitudinal Taxonomy of Silent Failures in a Production LLM Agent Runtime. arXiv 2606.14589, 12 June 2026. Preprint, one system, one operator. Graded entry.
- Dixit, H. D., Pendharkar, S., Beadon, M., Mason, C., Chakravarthy, T., Muthiah, B. and Sankar, S. (2021). Silent Data Corruptions at Scale. arXiv 2102.11245, 22 February 2021, Facebook, Inc. Graded entry.
- Hirji, R. (2026). The Agents Are Here. You're Just Not Paying Attention. Box of Amazing, 15 February 2026. Source of the Tokyo itinerary and of the line about holding agents to a standard of perfection.
Related SuperSkills research#
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
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