One zone lost power in London, and the banks went dark with it

Tuesday, just after 7am

Tuesday morning in London. People tapped their bank cards at the till and the payment was declined. Revolut transfers froze mid-send. Lloyds and HSBC customers could not get into their apps. In courts across England and Wales, video hearings stalled because the courts' video platform was down. Royal Mail tracking went quiet, and delivery networks wobbled.

None of these companies had a power cut. A Google Cloud data center zone did.

Just after 7am London time on Tuesday, October 20, a power event knocked out europe-west2-b, one of three availability zones inside Google Cloud's London region. Google's own status text put it plainly: "A power event caused an outage within europe-west2-b zone. The power event is mitigated."

What followed is the part worth studying. One zone, one of three, lost power. And banks, courts, and couriers across the country felt it.

Google has said it will publish a full analysis once its internal investigation is finished. Until then, nobody outside Google knows the complete chain of events. What follows is what the status page and the press record show, plus the mechanics of what a zone failure actually breaks. If you run anything in the cloud, this is your blast radius lesson for the week.

What Google said

The timeline, from Google's status page and press reports:

• Just after 7am London time (06:08 UTC), Tuesday Oct 20. The power event hits zone europe-west2-b. Google: "Multiple services are experiencing issues in the europe-west2 region."
• Through the morning. "Google Cloud services are unavailable in europe-west2-b zone; some services in europe-west2 region may experience elevated errors and intermittent network issues." The incident page listed dozens of affected products: Compute Engine, Google Kubernetes Engine, Cloud Run, Cloud SQL, Cloud Storage, BigQuery, Pub/Sub, Memorystore, Persistent Disk, Cloud Load Balancing, Virtual Private Cloud, and more.
• Around midday. Most services were back to normal by about 12:10pm London time, roughly six hours in. Full recovery of existing workloads was tentatively expected by early afternoon.
• Late afternoon. The Ministry of Justice confirmed the courts' Cloud Video Platform had still not fully recovered. Some wounds take longer to close.

The customer list reads like a tour of British daily life: Revolut, Lloyds, HSBC, Halifax, Barclays, Bank of Scotland, NatWest, Nationwide, credit-reference firm Equifax, Royal Mail, DPD, property site Rightmove. The Telegraph reported cards declined at tills. The Guardian reported courts disrupted and millions unable to move money.

What a zone is, and what dies with it

A quick glossary, because the rest of this piece depends on it.

A region is a geographic area where a cloud provider operates, like London. Inside each region are availability zones: separate buildings, or clusters of buildings, each with its own power feed, its own cooling, and its own network connections. The London region, europe-west2, has three: a, b, and c. The idea is simple. If one building has a bad day, the other two keep going.

Your virtual machine lives in exactly one zone. Your disk lives in one zone too, with copies kept elsewhere for safety, but those copies are managed by the platform, not by you.

So when the power goes in zone b, everything physically in zone b stops at once. Virtual machines halt instantly, with no graceful shutdown. Disks stop being reachable. Anything that had its database primary in zone b stops answering. There is no orderly wind-down. The lights go out and the machines stop.

This is the part people nod along to and then get wrong in practice, because "we run in multiple zones" feels like a shield. It is a shield with holes. Here are the holes.

Why the surviving zones did not just absorb it

Failover takes time. Nothing in a distributed system switches over instantly. A database has to notice its primary is gone, hold an election, and promote a replica. A load balancer has to fail several health checks before it stops sending traffic to dead backends. DNS answers are cached, and each cached answer has a TTL, a countdown timer after which it expires. During every one of those windows, requests fail. Multi-zone does not mean zero-downtime. It means downtime measured in minutes instead of hours, if everything works as designed.

Your dependencies have zones too. Your app can run happily in zone a and still die, because it calls something that lived in zone b. A database primary. A NAT gateway. A load balancer component. A queue. Google's own status text admitted the mechanism: services across the region saw "elevated errors and intermittent network issues" because of shared infrastructure dependencies. A zone is not a sealed box. The region shares plumbing, and the plumbing runs through every zone.

You could not build replacements during the fire. Read this line from the status page again: "Customers may not be able to yet create new workloads." The system that creates virtual machines and clusters, the control plane, was itself degraded. Your running apps are the data plane. The API that manages them is the control plane. They are different systems, and this event hurt both. The usual escape plan, spin up fresh capacity in the surviving zones, was partially locked during the exact hours people needed it. The fire escape was bolted during the fire.

Two zones doing the work of three is not the same as three zones. Failover plans quietly assume spare capacity. When a third of a region's machines vanish, the survivors absorb their load on top of their own. Everything gets slower, queues grow, and some things fail that would have survived a smaller shock. One engineer's account in the press said the peer zones did not fully absorb the load. Capacity is the quiet part of every failover plan, and it is the part nobody load-tests.

The single-region trap

Here is the structural fact that made this outage national news instead of a footnote: europe-west2 is Google's only UK region. Customers who had built everything in London, sensibly, to keep data close to users, had no second UK location to fail over to.

Multi-zone protects you against one zone failing. Nothing inside a single region protects you against the region's shared systems failing, or against a zone failure cascading the way this one did through shared dependencies. Real protection is multi-region: running in London and somewhere else, with a tested plan to shift traffic. That roughly doubles your bill and your complexity, which is why most teams do not have it. The banks that went dark on Tuesday are a reminder of what that savings costs.

This happened before

The London region has been here before. On July 19, 2022, during the hottest day ever recorded in the UK, cooling failed in a building hosting europe-west2-a. Google's engineers could not get temperatures down, so they deliberately powered down part of the zone to save the hardware. That decision terminated about 35 percent of the virtual machines in that zone.

Different zone, different cause, same lesson. A zone is a unit of failure. It can go dark from heat, from power, from a bad config push, from a backhoe through a fiber bundle. The cause changes. The shape of the failure does not.

Audit your own blast radius

"We run multi-AZ" is a claim. Here is how to check whether it is true.

# Where do your VMs actually live? Not where you think. Where they are.
gcloud compute instances list --format="table(name,zone.basename())"

# Are your Kubernetes nodes spread across zones, or quietly all in one?
kubectl get nodes -L topology.kubernetes.io/zone

Then ask the questions no dashboard answers for you:

• Which zone holds your database primary right now? Your managed database console will tell you. Write it down.
• If that zone went dark, how long until a replica gets promoted, and have you ever watched it happen? If the answer is "the docs say it is automatic," you have not tested it.
• Which zone do your NAT gateways, load balancers, and file stores live in? These are the shared plumbing. They have zones too.
• During the last incident, could you have created new capacity? If your control plane calls were failing, your runbook's step one was fiction.

The cheapest version of this audit is a game day: pick a zone, pretend it is gone, and walk through what breaks. The 2022 incident's official workaround was "relaunch your workloads in another region." That advice only helps if you know, before the bad day, that you can.

The question

Draw your blast radius on paper. Pick the single thing, a zone, a database primary, a region, whose failure at 7am would ruin your day. If you cannot name it, that is the audit, and it is overdue.

Do you know, right now, which zone your database primary lives in? When did you last check?