When London Went Dark: What the Google Cloud Outage Teaches Us About Hyperscaler Risk

On the morning of Tuesday, October 20, a large slice of the United Kingdom’s digital economy quietly went dark. A power failure at Google Cloud’s europe-west2 region — the company’s London data centre — triggered cascading failures across multiple cloud services starting at 06:08 GMT. By the time most workloads had recovered around 12:10 GMT, digital banks, delivery services, property portals and postal systems had all spent hours in varying states of dysfunction.

What Happened

According to Google’s service health dashboard, the incident was caused by “a power event” at the London facility. That phrasing — bland, technical, almost soothing — masked the real story: when the region flickered, so did the daily financial lives of millions of people.

Revolut, the digital bank with tens of millions of customers, reported disrupted ATM withdrawals, bank transfers and card top-ups. High-street giants Lloyds and HSBC confirmed customers had trouble accessing services, with Lloyds stating that “root issues have been resolved” and normal service was expected to resume. Downdetector logged hundreds of reports of problems across UK businesses, including property site Rightmove, delivery firm DPD and Royal Mail.

Revolut moved quickly to reassure users: “We can confirm that all our customers’ money and data are safe.” Google, for its part, promised a full incident report in the coming days.

Why One Building Matters So Much

The uncomfortable lesson from this outage is not about Google specifically. It is about concentration. Over the past decade, businesses that once ran their own server rooms have migrated wholesale to a handful of “hyperscalers” — Google Cloud, Microsoft Azure and Amazon Web Services — because renting massive, professionally run infrastructure is cheaper and, most of the time, more reliable than owning it.

But that efficiency has a flip side. As Alan Woodward, professor of cybersecurity at the University of Surrey, noted after the incident, only three hyperscalers have the infrastructure to handle data at UK scale, and these facilities remain “susceptible to localised infrastructure failures” with significant knock-on effects when so many organisations depend on them.

This was not even the first warning. An AWS outage last year disrupted video games, transport platforms and swaths of the internet for hours. Each incident follows the same pattern: a single failure in one region propagates outward through apps and services that assumed the cloud underneath them was effectively infallible.

The AI Boom Makes It Worse

Professor Woodward raised a point that deserves more attention than it usually gets: the problem is “intensifying with the AI boom.” As companies race to train and serve AI models, demand for hyperscale compute is exploding, and with it, dependence on an ever-smaller number of providers. Every AI feature bolted onto a banking app or a retail platform deepens the reliance on a few enormous data centres.

There is a bitter irony here. The same concentration that makes AI deployment economically viable for thousands of businesses also creates single points of failure with society-wide blast radius. When one London facility lost power, people could not reliably withdraw cash or receive parcels. Imagine the same failure during a peak shopping season, or across multiple regions at once.

What Engineers Should Actually Do

For engineering teams, the takeaway is not “abandon the cloud” — that ship has sailed, and hyperscalers still deliver extraordinary uptime. The takeaway is to stop treating any single region, or even any single provider, as a constant of nature:

  • Design for regional failure. Multi-region deployments are expensive, but Tuesday showed the price of assuming one region is immortal. Even a degraded-mode fallback in a second region beats a six-hour outage.
  • Question critical-path dependencies. If ATM withdrawals depend on one region’s health, that is an architectural decision, not an accident of fate.
  • Rehearse the failure. Chaos engineering exists precisely for this. Teams that practise regional failover recover in minutes; teams that don’t, improvise for six hours.
  • Watch the concentration trend. Regulators in the UK and EU are increasingly asking whether financial and public infrastructure should depend so heavily on three foreign-owned providers. Expect that scrutiny to grow.

The Bigger Picture

By Tuesday afternoon, services were largely restored, shares of affected companies were mostly unaffected, and the tech news cycle moved on to the next story. That is precisely why incidents like this one are so dangerous — they are survivable, forgettable, and therefore repeatable.

Google’s incident report, when it arrives, will describe the power failure in detail: what tripped, what failed over, what didn’t. It is worth reading. But the more important document is the one no vendor will write: an honest accounting of how much of our collective digital life depends on a handful of buildings run by three companies — and whether that trade-off still makes sense as the AI era multiplies our reliance on them.

Cloud computing remains one of the great productivity engines of the modern economy. But October 20’s London outage is a reminder that “someone else’s computer” is still a physical thing, in a physical place, plugged into a physical power grid. Plan accordingly.