TL;DR: On 20 October 2026, a power event in one London zone, europe-west2-b, made Google Cloud services there unavailable and caused errors across the rest of the region. Google's status page ran from 06:08 to 14:00 UTC, about eight hours, and listed 38 affected products.
- It was one zone, not the whole region. Google says the outage was "within europe-west2-b zone", while other London zones saw "elevated errors and intermittent network issues".
- Most workloads were back by 12:10 UTC, six hours in. Google closed the incident at 14:00 UTC and says it will publish an analysis.
- The apps that went down were the ones that lived in one zone. Google's workaround all morning was to move the workload "to another available location (zone or region)".
- The banks that stayed up had a second system on a different cloud. Monzo runs a stand-in bank on Google Cloud for when its main platform on AWS fails.
- Your rented server is a zone too. One box in one data center has one power feed, so the fix for a small app is the same, at a smaller scale: a second server somewhere else.
A zone is one or more data centers inside a cloud region. A region like europe-west2 (London) has several, and a well-built app runs in more than one so it survives losing one.
What failed, and when
Times are UTC, from Google's incident page.
| Time | What Google posted |
|---|---|
| 06:08 | Issue begins with "multiple services in europe-west2" |
| 08:35 | First update: elevated errors and intermittent network failures; workaround "None for now" |
| 09:24 | Workaround: move workloads to another zone or region |
| 11:12 | Cause: "a power event" in europe-west2-b, now mitigated |
| 11:58 | Existing workloads come back first; new ones may not start yet |
| 12:10 | Most workloads in europe-west2 recovering |
| 14:00 | Mitigated "for most of the customers"; no further updates |
The 38 products include Compute Engine, Kubernetes Engine, Cloud Run, Cloud SQL, AlloyDB, Memorystore, Cloud Storage, Persistent Disk and Cloud Load Balancing. That's the compute, the databases and the load balancer, so an app that kept all three in one zone had nothing left to serve from.
Who went down
Neowin's headline named HSBC, Revolut, Bank of Scotland, Lloyds and Equifax. On Hacker News, Revolut customers said they couldn't pay or withdraw all morning, and one couldn't pay for groceries until they added another bank's card. An HSBC customer said everything worked for them, and pointed out that most outage lists come from Downdetector, where users report problems.
So treat any list of names with care. What's on record is Google's: one zone lost power, and services across the region had errors.
Why multiple zones weren't enough
The comments kept coming back to one question: why didn't these companies fail over to another zone? Three answers came up.
- Zones aren't always separate buildings. Google's own docs say a region has "three or more zones housed in three or more physical data centers", except Stockholm, Osaka and Montreal, which "have three zones housed in one or two physical data centers".
- Failover nobody tested doesn't exist. One commenter: "Everywhere I've worked has had multi-AZ infrastructure. I have never worked anywhere where the failure of an AZ has been simulated regularly."
- When a zone dies, everyone moves at once. Several commenters said the other zones then run short of capacity, and one with workloads in other London zones said they were affected too.
The answer that held up came from Monzo customers. Monzo's Stand-in is "an independent set of systems that run on Google Cloud Platform" that can take over from its main platform on AWS. It runs fewer features, on different code, on a different cloud, so one provider's bad day can't take both down.
You don't need a bank's budget to run on two providers. With Ployz, a Hetzner server and a server from another provider join one private network, and your app runs on both, each with its own load balancer. Put your app on two providers with Ployz.
The rest of the week on hosting platforms
Google wasn't the only one. Platforms built on top of clouds had their own incidents between 14 and 20 October, from their status pages:
| Date | Platform | What broke | How long |
|---|---|---|---|
| 14 Oct | Render | Builds and deploys not starting, all regions | 2h 46m |
| 15 Oct | Render | Dashboard not updating live, some Workflows requests timing out, from "an upstream cloud provider" | about 2h 45m |
| 16 to 17 Oct | Fly.io | Rolling reboot of every host; apps, volumes and Postgres on each host down 15 to 20 minutes | 12h 53m end to end |
| 17 Oct | Supabase | Project creation failing in Tokyo, from "an upstream provider outage" | 1h 22m |
| 20 Oct | Netlify | Agent Runner failures | 1h 08m |
Only Fly.io's touched running apps, and only for minutes at a time. The rest stopped deploys or dashboards. My list of 2026 hosting outages has the full year.
What a small app should copy
A bank needs a second bank on another cloud. A small app needs much less, but the shape is the same.
- Know your blast radius. One rented server is one zone: one building, one power feed. If it goes dark, so does your app.
- Keep a copy of the database somewhere else. A backup on the same server dies with the server.
- Add a second server in another location. Hetzner alone has data centers in Germany and Finland, and a second provider protects you from an account problem as well as a power cut.
- Run the app on both. Two copies behind two addresses mean losing one server costs you capacity, not the site.
- Turn one off on purpose. Do it on a quiet morning, before a power event does it for you.
Where Ployz fits
I build Ployz, so take this part with that in mind. Servers from different providers join one private network, and every server runs its own load balancer. You or your coding agent pick which servers a service runs on and how many copies, up to 50, so the same app can run in Falkenstein and Helsinki at once. Moving a service or a database to another server is one call, and draining a server waits for you.
Deploy your app on your own servers.
FAQ
Is Google Cloud europe-west2 down right now?
No, Google marked it mitigated at 14:00 UTC on 20 October 2026. Its last update said "a very small number of customers" were still affected and should open a support case.
What caused the Google Cloud London outage?
A power event in the europe-west2-b zone, according to Google's status page. Google says it will publish a full analysis.
Where is europe-west2?
London, in the United Kingdom.
Does running in multiple zones protect you?
Usually, but not always. Losing a zone can overload the others, and a region's zones may share buildings, so the stronger protection is a second region or a second provider.
How do I make a small app survive a data center outage?
Run it on two servers in two locations, keep the database's backups off both, and test it by switching one off. That's the same plan as a bank's, at the size of one app.
How I checked
I read Google's incident page and its incidents feed on 21 October 2026, and quoted the times as posted. The platform incidents come from the Render, Fly.io, Supabase and Netlify status pages. I took the zone definitions from Google's "Geography and regions" docs and the Stand-in quote from Monzo's blog. I didn't check which banks were affected beyond what customers reported in the thread, because Neowin's article blocked my request and none of the banks has published a cause.