The status page began posting errors in the morning and kept posting them. Multiple Google Cloud services in the company’s London region were disrupted on October 20, and Revolut, the British digital bank, reported that payments, transfers and withdrawals were affected at the same time. Rightmove, the property portal, told users something was wrong. Google later apologized and attributed the problem to a data center in London, without saying when full service would return.
The sequence is familiar because it happened a year ago, almost to the day, when a domain name system failure in Amazon’s northern Virginia region took down a long list of consumer services for hours. The provider changes, the mechanism changes, and the result does not: a single facility, or a single control plane inside it, becomes the failure domain for companies that believed they had bought redundancy.
Cloud regions are sold as three zones, each with independent power, cooling and network paths. That architecture is real and it works against the failures it was designed for, which are hardware and utility faults confined to one building. It does not work against the failures that actually cause long outages, which tend to sit in the layers above the zones: identity, DNS, the internal APIs that provision resources, the load balancers that decide where traffic goes. When those break, three zones behave like one.
Revolut is the kind of customer that makes an outage visible. It holds a British banking license with restrictions, has been adding customers across Europe at a rate that put it among the largest fintechs by user count, and processes a volume of payments that makes any interruption a matter for its regulator as well as its support queue. A bank whose app will not move money is, for the duration, not a bank. Customers do not distinguish between the institution that failed and the vendor underneath it.
The concentration is a rational choice that becomes an uncomfortable one. Running on two clouds doubles the engineering headcount, splits the data, and forces every service to be written twice or wrapped in a layer that costs latency and money. Providers price accordingly, with committed-spend discounts that make a second cloud look like an unnecessary expense right up until the morning it isn’t. Most companies that say they are multi-cloud mean they use different providers for different products.
British regulators have spent three years building a framework for exactly this dependency. The critical third-party regime lets the Bank of England, the Prudential Regulation Authority and the Financial Conduct Authority set requirements directly on the large cloud providers that financial firms depend on, an authority they previously exercised only over the firms themselves. Operational resilience rules require banks to name their important business services and to show they can keep them running through a severe but plausible disruption.
Those rules have an awkward feature. They test the firm’s ability to continue, not the vendor’s ability to avoid failure, and the firm’s plans generally assume the vendor is doing its part. An outage caused by one data center in one region is precisely the scenario the plans describe as survivable, which means the plans were either wrong about the architecture or optimistic about the failover.
The commercial terms do little to change behavior. Cloud contracts offer service credits measured in percentages of the monthly bill, and a bank that loses a day of payment processing loses far more than the credit is worth. The credit is not compensation; it is a discount on a service that did not work. Insurers have started to ask about cloud concentration when underwriting business interruption, and the answers are difficult to give in a schedule.
What customers experienced was not a cloud outage. It was a payment that did not arrive, in a shop, on a Tuesday. The distinction matters because it explains the pressure that follows: the bank’s regulator asks the bank, the bank asks the provider, and the provider publishes a status update. Nobody in that chain can restore the transaction that failed.
Google’s statement gave no timeline for full recovery, which is standard for an incident still being worked and unhelpful for anyone planning around it. The company has invested heavily in its London presence, including a region it has operated since 2017 and a substantial office and infrastructure buildout since. Reputation in cloud infrastructure is not built on the absence of incidents, which no provider achieves, but on how quickly the provider can say what broke and what it will change.
The deeper issue is that the industry has optimized for cost and latency, both of which reward concentration, and has priced resilience as a feature rather than a requirement. Regulators are now trying to move it into the requirement column, slowly, through the entities they can reach. That work will take years, and the outages will keep arriving in the meantime, each one finding the same seam.
By the evening, service was being restored in stages. The region will return to normal, the postmortem will describe a facility-level fault and a failover that did not behave as documented, and the customers who lost a day of transactions will be offered credits they did not ask for. The next failure will be at a different provider, in a different city, and it will take down a different set of companies that also thought they had three zones.
