"One in ten outages is now AI": that figure measures something else

Three studies on AI and reliability have been going round together this week, and of the three the one that got shared most says one outage in ten is now an AI outage. The number is real and it comes from a serious report. What is not true is what people are taking away from it. And that same report holds another figure, which nobody has repeated, that genuinely should change a decision for you this week.

What exactly that 10.7% counts

The source is StackGen's State of Reliability 2026, and the report's own fact sheet is transparent about method: 109,000 incidents gathered from public status pages, from over 390 companies, across thirteen sectors, in a window running from 2018 to 2026. It is a counting exercise, not an exercise in assigning blame: somebody went to the pages where companies publish their own incidents and counted them.

Within those thirteen sectors there is one grouping providers of AI models and AI applications. The headline figure is that sector's share of all published incidents: 10.7% so far in 2026, around six times what it was three years earlier. Put in the exact terms of what it measures: one published outage in ten was published by an AI company. Which is not the same as "one outage in ten was caused by AI", and the difference is not a matter of phrasing: it is the difference between a market-share figure and a causal one.

Part of that climb is the make-up of the census. In 2023 that sector barely registered in the count because it barely existed as a sector; today it carries weight, and if tomorrow the number of AI companies with a public status page doubles, the percentage rises again without a single agent having broken anything new. How much of it, we do not know: the fact sheet publishes the year-by-year series — 0.6%, 1.7%, 4.0%, 6.9% and 10.7% — but does not say whether the base of companies is the same at each step, and without that nobody can separate a sector that is growing from a sector that is breaking more. What is clear is what that 10.7% does not answer: who broke it.

The report itself says so from the other direction, and credit where it is due: it warns that its own measurement of AI is a floor, because it only counts incidents published by AI companies and leaves out everything AI breaks inside companies that are not. Both things are true at once: the number does not prove what the headline implies, and AI as a cause is something the report counts separately, not there — at least eleven documented cases of agents that wiped data or destroyed live systems since mid-2025, with the warning, verbatim, that the true count is unknown because a status page cannot see it. The honest conclusion is uncomfortable and not very shareable: that 10.7% does not answer the question everybody is asking it. This has happened to us before with figures that sound like verdicts — we wrote about it recently in connection with a bulletin carrying ten vulnerabilities in one process: the headline is not enough to decide.

The number in that same report that does decide something

Further down, on the same fact sheet, there are two medians placed side by side. They have not made a single headline, and they are the only thing in the whole report we find directly applicable to an architecture decision.

Two and a half hours of difference, or to put it another way, two and a half times as long down when the thing that breaks belongs to a supplier of yours. And it is not because your people are worse in those cases: it is that in those cases your people can do nothing except refresh somebody else's status page and answer emails. The report adds that 26% of assessed 2026 incidents are third-party cascades, and warns that the 26% is also a floor, because around 16% of recent incidents are unclassified and anything unclassified counts as "not a cascade".

An annual availability total tells you nothing about it; we wrote that up yesterday with the arithmetic in full: the 99.9% does not tell you how long the outage lasts. What the office feels is the width of the gap, and here there are two very different widths depending on who owns the piece that broke.

And this is where your agent comes in

An AI agent dropped into a business process is not, from a reliability standpoint, a new function in your software. It is one more supplier on the critical path: a third party's API that can be slow, can be down, can cut you off on quota at eleven on a Tuesday, and can hand you back something different from yesterday without you changing a single line. Those four things are the exact profile of what the report calls a third-party cascade. The 247 minutes are not the punishment for using AI: they are the price of putting a dependency you do not administer somewhere your revenue depends on.

That gives you the first boring decision, and it is the same one we make with container images: pin the model version. If you call an alias the provider keeps moving, you have agreed that the component can change underneath you without your permission and outside your calendar. It is precisely the mistake we already wrote about in "latest" is not a version, transplanted somewhere few people are watching. And the second boring decision is identity: an agent working with a person's token leaves no trail of its own, and we covered that in full in the log will not name the agent, it will name whoever lent the token.

The other two studies, read with the same magnifying glass

The second comes from IBM, was run by Censuswide and was published on 14 October. It covers 3,221 executives at organisations of over a thousand employees across eight countries — Spain among them — surveyed between 14 and 24 September. Two pairs of figures worth reading together:

From the same study: 35% say they have agentic AI in production today, 75% expect their agents to have some degree of decision autonomy by 2027, and only 37% believe their governance is designed to scale with that. There is a gap of nearly forty points between what they expect to delegate and what they believe they can govern — and it is a gap declared by the people responsible themselves.

The third is the one circulating most among engineers: a VB Intelligence survey in which, among companies already deploying autonomous agents, the share that allows certain production changes on an automated evaluation result alone — or is engineering its systems to allow it within a year — fell from 75% to 56%. Before you use it in a meeting, look at its own method: two waves, of 108 and 140 responses, a month apart — July and August 2026. That is not a time series, it is a blurred photograph; with those samples and that interval, the drop could be a change of mood across the sector or it could be that different people answered in August. Which is, in fact, what its own methodology note says: the two groups were separate and self-selected, and August's had more final purchasing decision-makers than July's — 53% against 44%. We would not use it as evidence of anything.

What is worth keeping from that same piece of work is another figure, less quoted and far more useful: among those who run evaluations before deploying, 61% admit at least one case in the past year where an agent or a language-model feature passed internal testing and then failed in front of the customer; 22% more than once. And read calmly, that is not an AI problem. It is the classic symptom of a test environment that does not resemble production, the same one Oppenheimer, Ganapathi and Patterson described at USENIX in 2003 when they found operator error was the single largest cause of outages in two of the three services they measured, and that configuration was the largest category within it. The agent does not bring a new failure mode: it brings one more operator touching production, who works at night, never tires and asks nobody.

The switch-off test

Before you leave an agent inside a process somebody cares about, there is a test that costs twenty minutes and requires buying nothing: switch it off on purpose, on a Tuesday at eleven in the morning, with people watching. It is backyard chaos engineering, the cheap version of what the big players do with tools that break things on their own, and something we have already written about with a hypothesis and a blast radius in testing the live system would have prevented 26 of 40 outages. And it gives you one of these three results:

If you get the third result, the work you are missing is not AI work, it is craft: the model version pinned, the agent's own credential scoped to what it needs, a short list of what it may write and what it may only read, the name of a person who can switch it off, an alert that fires when it stops answering — not when the customer complains — and the path without it, written down. Those are the same six boxes we have asked of any production service since long before agents existed. We run our own self-hosted n8n automation doing internal tasks every day, and it sits in the inventory with an owner and a maintenance window, like everything else. Not because it is AI, but because it does work somebody depends on.

When not to put the agent in

We sell automation, so this part is worth reading with your eyes open. There are two cases where we say no, and we say it early because later it costs more.

The first: if the process cannot be done by hand, however slowly and badly, the agent is not the problem — the process is not ready to be automated. Automating something nobody knows how to do manually does not remove work, it hides it, and it hands it all back on the day the provider has a bad one. The second: if the only reason for putting it in is that this quarter you need to be able to say you use AI, the real cost is not what the model calls cost. It is the 247 minutes of the day it does not answer, multiplied by what your company bills in a morning.

The axis we measure any design against does not change because the new component happens to be a language model: failure is inevitable, an outage is a design decision. Your agent is going to go down, just as a disk goes down or a large provider does. If the process is built to limp along without it, that is paperwork. If it is built so that without it there is no process, that is four hours of a company standing still — and somebody chose them on the day they plugged it in without running the switch-off test.

Sources and method: the incident-count figures, the two medians (247 and 96 minutes) and the third-party cascade share come from the public fact sheet of StackGen's State of Reliability 2026 — stackgen.com. A reading caveat: various press write-ups quote volume figures different from the fact sheet's (we have seen "almost 180,000 records" against the 109,000 incidents on the sheet itself); most likely those are total status-page entries against unplanned incidents, which is what the sheet counts and what corresponds to "outage", but we have not been able to confirm it, so we use the sheet's figure throughout. The interpretation that the 10.7% measures sector share rather than causation is ours, not the report's; the report points in the opposite direction (it warns that its own measurement of AI is a floor) and both can be true at once. The governance figures come from IBM's The New Realities of AI Governance Report, conducted by Censuswide between 14 and 24 September 2026 with 3,221 executives at organisations of over 1,000 employees in the UK, France, Germany, Italy, Spain, the Netherlands, Saudi Arabia and the UAE — newsroom.ibm.com. The figures on trust in unreviewed changes and on failures after passing evaluations come from the VB Intelligence survey (July and August 2026 waves, 108 and 140 responses) — venturebeat.com; we quote them with their sample size attached because they read worse without it. The study on causes of failure is D. Oppenheimer, A. Ganapathi and D. A. Patterson, "Why Do Internet Services Fail, and What Can Be Done About It?", USENIX USITS 2003 — usenix.org; it measures only three specific services, so we cite it for the direction it points in and not as a universal statistic. What we say about our own n8n automation is ours, and carries no number: we do not publish internal metrics nobody can check.