The record attack lasted thirty-five seconds

The outages nobody caused

Meanwhile the actual unavailability moved somewhere else entirely. A single cloud region has produced an outage of about 28 hours; another incident generated something like 17 million public reports over 15-odd hours. In two of the three most disruptive recent events the cause was a configuration or metadata change rather than hardware, capacity or anybody hostile. Somebody deployed something, and a fifth of the visible internet stopped answering.

This is not a story about incompetence at large providers, whose engineering is generally better than that of their customers. It is a story about correlation. The same three suppliers hold roughly 66% of the cloud market; one front-line network sits ahead of something like 20% of the web. When the failure domain is that large, an ordinary mistake — the kind every engineering organisation makes monthly — produces a national event instead of an incident report.

The exposure is understood and unresolved. Around 81% of organisations say a 7-day outage at a single supplier would cause severe or critical disruption, which is a remarkable thing for four fifths of a market to agree on and then do nothing about. The reason they do nothing is that the alternatives are worse: running elsewhere costs more, running in two places costs much more, and the outages, however dramatic, remain rarer than the savings.

That calculation is defensible, and it stops being defensible the moment nobody has done it explicitly. An organisation that has weighed a rare multi-hour outage against permanently higher costs and chosen the outage is managing a risk. One that has never asked is carrying the same risk and calling it an architecture.

Cheaper than resilience

The instinctive response to concentration is duplication, and for most organisations it is the wrong one. Running a genuinely independent copy of a service at a second provider means two of everything, including two sets of operational knowledge, and introduces its own failures: divergent configuration, data that disagrees between the copies, and a failover procedure exercised once a year by people who are nervous. The expense is certain and the benefit arrives only in the rare event.

The cheaper move is a degraded mode. Decide in advance what the service does when a dependency is missing, and build that instead of building redundancy. Read-only when the database cannot be written. Cached prices when pricing does not answer. Card details captured now and authorised later when authorisation is unreachable. Each is a modest piece of engineering, each converts an outage into an inconvenience, and each works against causes nobody predicted, including the ones inside your own building.

The second cheap move is knowing which services genuinely cannot stop. Most organisations, asked to name them, produce a list of three or four and are surprised by how short it is — and by how much of the estate turns out to tolerate a day offline without anybody minding. That distinction is the entire basis for spending proportionately, and it is the one supervisors in financial services now require firms to write down precisely because so few did it voluntarily.

Third, rehearse the restoration rather than the backup. Almost every organisation takes copies and a startling number have never timed a full recovery, which is the only figure that matters when the question arrives. Restoring a large database from cold storage across a slow link can take days, and discovering that during the incident converts a bad afternoon into a bad week. The number to obtain is simple: how many hours from the decision to restore until customers can transact again, measured once, honestly, on real volumes.

Fourth, and easily forgotten in a subject dominated by digital failures: much of what stops an organisation is physical and prosaic. A power distribution board, a cooling failure in a comms room nobody has entered in two years, a single fibre route between two buildings that the map shows as diverse and the ground does not. These have no attacker, no advisory and no vendor, and they cause a steady trickle of days lost that never appears in any security report. The organisations that handle them well are usually the ones with somebody old enough to remember when this was the whole job, and the ones that handle them badly have generally never walked the route their diagram claims exists. Walking it is a morning of somebody's time, needs no budget approval, and has an unusually high rate of producing a finding: the two supposedly separate feeds entering the same duct, the generator that has not been run under load since it was installed, the door held open by a wedge because the card reader is slow. None of those appear in a scan, and each of them has taken an organisation offline at some point this year.

Last, and least glamorous: keep the thing that reports the outage away from the thing that has the outage. Status pages behind the same front-line network as the service they describe are common, and they fail at the exact moment their purpose begins. A page hosted somewhere unrelated, with a name resolved somewhere unrelated, costs nothing and is the difference between an outage and an outage nobody can get any information about.

What is an availability guarantee worth?

Less than its arithmetic suggests, and far less than its reputation. Three nines of promised availability permit roughly nine hours of absence a year, four permit under an hour, and both are measured by the supplier, over a window the supplier defines, excluding whatever the contract lists as maintenance. A month containing a multi-hour outage can comfortably remain inside a headline figure that sounds like a guarantee of continuity.

What the agreement actually provides is a refund. Miss the target and the customer receives credits calculated as a percentage of that month's fee, capped, claimable within a window, and payable in further service rather than money. For an organisation whose revenue depends on being open, the compensation for a day offline is a partial discount on a subscription — a sum with no relationship whatever to what the day cost.

None of which makes the document worthless; it makes it a different document than people assume. It is a statement of intent, a definition of what counts as being down, and a mechanism for noticing. Read it for the definitions rather than the numbers: what the supplier counts as an outage, whether partial degradation counts at all, who declares it, and how you would prove your own case if the two of you disagreed about whether the service was working.

The practical consequence is that availability has to be bought with engineering rather than with contract terms. No clause has ever kept a service running. What clauses do is tell you which failures the supplier considers its problem, and everything outside that boundary remains yours regardless of what you paid.