One Google Cloud zone went dark. Whole banks went with it

On the morning of October 20, 2026, a power failure in a single Google data center in London took down Revolut's app and cards, Halifax's online banking, live streams of British court hearings, and parts of Spotify and DPD. Google described it in one line: a "power event" in zone europe-west2-b. One zone. Cloud architecture exists precisely so that losing a zone is a non-event. When it becomes a headline, the useful question isn't "why did Google go down" — it's "why did so much depend on one building".

What actually happened

The confirmed facts are few, and worth keeping apart from speculation:

• Google Cloud's status page opened an incident in the europe-west2 (London) region with 28 affected products, from AlloyDB to Apigee and BigQuery.
• Google attributed it to a power event in zone europe-west2-b and said it was mitigated around noon UK time.
• Revolut reported failures in card payments, transfers, withdrawals and login, and said "customers' money and data are safe". Halifax confirmed app and online banking issues.
• The UK courts service lost the video platform used for remote hearings, per ABC.

What we don't know yet: why each of these companies failed to absorb the loss of one zone. Google's postmortem will explain its side. Each customer's side will probably never be public.

Zones, regions, and the promise nobody reads

At the major cloud providers, a region is a geographic area (London) and a zone is an isolated set of data centers inside it, with its own power, cooling and network. A typical Google region has three zones. The promise is simple: zones fail independently, so anything running in more than one survives losing any of them.

The detail the coverage skips is that this protection is not the default. It depends on how each piece was provisioned:

A system is only as resilient as the most zonal piece on its critical path. One session store, one auth service or one third-party vendor in a single zone is enough to turn a "contained" failure into a full outage.

Why "regional" doesn't always hold

Even teams that did the homework can go down, and this is the mechanism worth understanding:

1. Failover is a wave, not a switch. When a zone disappears, all its traffic rushes to the other two at once. If the surviving zones had no spare capacity, they choke — and losing a third becomes losing everything.
2. Hidden dependencies. A managed service can be regional for data and still depend on components that aren't. Today's incident listed 28 products degraded across the region, not just in the zone that lost power.
3. Untested failover is a hypothesis. Replicating data is the easy part. Promoting the replica, reconnecting apps and draining queues without duplicating a bank transfer is the part you only find broken on the day.

None of these is exotic. They are the normal consequences of an architecture drawn on a diagram and never switched off on purpose.

The part that costs money

Redundancy is a budget decision dressed up as a technical one. Running across three zones costs more in infrastructure and, above all, in engineering: the app has to be stateless where possible, the database has to tolerate a primary switch, and someone has to rehearse the failure.

The bill on the other side is what happened today: hours of declined payments, customers locked out of their own money, a brand printed next to the word "outage" in every headline. For a bank, that is a regulatory event. For a startup, it can be the day the biggest customer decides not to renew.

The most common mistake we see isn't choosing too little redundancy. It's not knowing you chose. Zonal was the default on the first deploy, nobody revisited it, and the product grew on top of it.

What we'd do on Monday

If your product runs on a public cloud, this checklist is worth an afternoon:

1. Map the critical path. Login, payment, the main screen. For each component on it, write down: zonal, regional or multi-region?
2. Find the zonal link. There almost always is one — a Redis, a worker, a single-replica database. Decide on purpose whether it stays that way.
3. Ask your vendors. Your auth provider, payment gateway, email service: where do they run, and what happens if their zone fails?
4. Rehearse the outage. Take a zone down in staging and watch. A failover that was never tested doesn't count as redundancy.
5. Design the degraded mode. If payments fail, does the app still show the balance? An honest message beats an infinite spinner.

It's the same discipline we apply when taking products to production: the gap between working in the demo and surviving the bad day. In live events, like Ultimate Drift, we assume the piece will fail at the worst possible minute — because the worst minute is exactly when everyone is watching.

Key takeaways

• The October 20 outage started in a single zone of Google Cloud in London, from a power failure, and took down banks and public services.
• In the cloud, cross-zone redundancy is not the default: zonal resources go down with their zone.
• A system is only as resilient as the most zonal component on its critical path, vendors included.
• Even regional architectures fail when failover was never tested or surviving zones have no headroom.
• How much to pay for redundancy is a business decision. The problem is making it without knowing.

FAQ

What caused the Google Cloud outage on October 20, 2026? According to Google, a power event in zone europe-west2-b in London. The incident affected 28 products in the europe-west2 region.

What's the difference between a zone and a region? A region is a geographic area; a zone is an isolated set of data centers inside it, with its own power and network. Multiple zones protect against one zone failing; multiple regions protect against the whole region failing.

Would switching providers fix this? Not by itself. AWS and Azure use the same zone-and-region model with the same rule: redundancy is something you provision and configure.

Is multi-cloud the answer? Rarely for a startup. The cost of operating two providers usually exceeds the risk it removes. Well-tested multi-zone solves most of the problem at a fraction of the cost.

How do I know if my product is exposed? List the components on your critical path and check where each one runs. If any is zonal, or you can't answer, that's your exposure.