Google Cloud London Outage: Why One Zone Took Down Banks

By Jaspal Singh October 21, 2026 Updated: October 21, 2026

A power failure in one of Google Cloud's three London zones, europe-west2-b, disrupted dozens of cloud products for roughly eight hours on 20 October 2026, and banking, retail and delivery apps that ran there went down with it. The lesson is blunt: spreading across zones protects you only if failover works when you need it.

What Happened

According to Google Cloud's Service Health incident page, the problem began at 23:08 Pacific time on 19 October, which was 07:08 in London and 06:08 UTC on 20 October. Early updates described elevated errors and intermittent network failures in the London region, europe-west2, with engineers still investigating the cause. For the first few hours, Google's suggested workaround was "None for now." From the 02:24 Pacific update onward it advised customers to move affected workloads to another zone or region where they could.

At 04:12 Pacific (11:12 UTC) Google said the "power event" had been mitigated and that partial infrastructure recovery should follow within 30 minutes. A later update said most workloads had recovered as of 05:10 Pacific, but warned that customers "may not be able to yet create new workloads." At 07:03 Pacific (14:03 UTC) Google declared the issue mitigated for most customers, said a very small number were still affected, and stopped posting updates. Its one-line explanation was that a power event caused an outage within the europe-west2-b zone.

The status page lists 38 affected products, from Compute Engine, Persistent Disk and Google Kubernetes Engine to Cloud SQL, Cloud Spanner, Cloud Storage, BigQuery, Pub/Sub, Memorystore and Cloud Load Balancing. The Register reported that customers hit included Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Screwfix and Revolut, and that Google pointed reporters back to the status page rather than giving more detail.

Revolut drew the most attention. The Next Web, citing Reuters, reported that Revolut's problems began around 08:00 UK time, about an hour after Google's incident started. Users in the UK, Ireland, France, Spain, Romania and Germany reported card payment and cash withdrawal failures. Revolut, which has more than 80 million personal customers and runs its app and back end on Google Cloud, said only that customers' money and data were safe. A person familiar with the matter told Reuters the disruption was tied to the Google Cloud incident. Google says it will publish an analysis once its internal investigation is complete.

Why It Matters

Cloud providers sell zones as the basic unit of fault isolation. One zone failing should be an inconvenience, not a headline. On 20 October, the failure of one zone in one city stopped people across six countries from paying with their cards. That gap between the design promise and what customers experienced is the real story.

It also shows how concentrated Britain's digital infrastructure has become. Banks, the national postal service, a major property portal, a parcel carrier and a telecoms group all shared a dependency most of their customers had never heard of. When people talk about "concentration risk" in cloud computing, this is what they mean: many independent brands that turn out to have one physical point in common.

For anyone who runs software, the outage is a free stress test. Most teams believe their system survives a zone loss because they deployed into more than one zone. Far fewer have tested what happens when a zone dies, its neighbours slow down under the surge of failover traffic, and the control plane is too busy to start new machines. Similar regional events, such as the drone strikes that took AWS zones in Bahrain and the UAE offline earlier this year, show these are not purely theoretical risks.

How It Works

Google's regions and zones documentation explains the structure. A region is an independent geographic area, such as London. A zone is a deployment area inside a region, and London has three of them: europe-west2-a, -b and -c. Google says it designs zones "to minimize the risk of correlated failures" from physical infrastructure problems such as power and cooling, and links them with high-bandwidth, low-latency networks so applications can span them. Its standing advice is to deploy important systems across multiple zones and, for the strongest independence, across multiple regions.

Zonal, regional and multi-regional resources

Cloud resources come in three scopes. A virtual machine and a standard persistent disk are zonal: they physically live in one zone, and if that zone loses power they are gone until it comes back. Regional resources, such as regional managed instance groups, regional GKE clusters or high-availability Cloud SQL, keep copies in two or more zones and are meant to fail over automatically. Multi-regional services, such as some Cloud Storage and Spanner configurations, replicate across regions.

A single-zone power failure should only take down zonal resources. Regional services should lose a replica and keep running. So why did 38 products report problems? Google has not yet said, but there are several familiar ways a zone failure spreads beyond its zone.

Why one zone can ripple out

Single-zone deployments. Many workloads run in one zone because it is cheaper and simpler, or because a database or legacy component was never made redundant. Those workloads simply went dark.

Failover capacity. When a zone fails, every multi-zone customer shifts traffic and tries to start replacement machines in the two remaining zones at once. If those zones lack spare capacity, new VMs queue or fail. Google's own warning that customers "may not be able to yet create new workloads" points to exactly this kind of pressure on the control plane.

Shared regional services. Load balancers, networking, managed queues and storage are regional, but each runs on machines in particular zones. Losing a third of a region's hardware can push those services into elevated error rates even when they never fully fail, which matches the "intermittent network failures" Google described.

Stateful data. Stateless web servers are easy to move. Databases are not. If a primary database lives in the failed zone and replicates to another zone asynchronously, promoting the replica can lose the most recent writes, so teams at banks often hesitate before failing over. Synchronous replication avoids data loss but adds latency, and some teams decline that trade-off.

Hidden dependencies. An app may be multi-zone while a third-party fraud check, an identity provider or an internal logging pipeline is not. Card payments need every link in the chain to answer within a second or two. One slow dependency is enough to make the whole transaction time out.

Measuring resilience

Engineers describe resilience with two numbers: the recovery time objective (how long you can be down) and the recovery point objective (how much data you can afford to lose). Cloud service-level agreements generally promise higher availability for workloads spread across zones than for a single instance, and they pay out in service credits, not compensation for lost business. A provider's SLA is a refund policy, not an architecture. The architecture is the customer's job.

What's Still Unknown

Google has not explained what the "power event" was, whether it was a grid problem, a failed transfer switch or a fault inside the building, or why backup power did not hold. It has not said why products it sells as regional, such as Cloud SQL, Spanner and load balancing, reported impact, or how many customers were affected. The promised incident analysis should answer some of this.

It is also unclear why Revolut, which runs its core systems on Google Cloud, could not shift traffic to the London region's other two zones or to another region quickly enough. Revolut has not published a post-incident account. Whether UK regulators will ask questions is another open point: Britain's financial authorities have spent several years building rules for "critical third parties" that supply the finance sector, and an outage affecting several banks at once is exactly the scenario those rules were written for. Coverage so far has not reported any regulatory statement.

Frequently Asked Questions

What caused the Google Cloud outage on 20 October 2026?

Google says a power event caused an outage inside europe-west2-b, one of three zones in its London region. It has not yet explained what failed or why backup power did not prevent the outage. The company says it will publish a detailed analysis once its internal investigation is finished, which usually includes a root cause and a list of fixes.

How long did the Google Cloud London outage last?

Google's status page dates the start to 06:08 UTC on 20 October. It reported the power problem mitigated around 11:12 UTC, said most workloads had recovered by about 12:10 UTC, and declared the issue mitigated for most customers at 14:03 UTC. That is roughly eight hours from first errors to near-full recovery, with a small number of customers affected afterwards.

Which companies were affected by the outage?

The Register named Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Screwfix and Revolut among the customers hit. Revolut users in the UK, Ireland, France, Spain, Romania and Germany reported failed card payments and cash withdrawals. Many smaller businesses running in the London region were probably affected too, though Google has not published a customer count.

Was my money safe if my banking app stopped working?

Revolut said customers' money and data were safe. An outage like this affects the systems that process transactions and show balances, not the funds themselves. Payments that failed during the disruption normally do not go through, so it is worth checking your transaction history afterwards for anything that went through twice or not at all, and contacting your bank about any discrepancy.

What is the difference between a zone and a region?

A region is a geographic area, such as London, that contains several zones. A zone is a separate deployment area within that region, designed with its own power, cooling and networking so that failures stay contained. Applications spread across zones should survive a single zone failure, while spreading across regions protects against an entire city's data centres going offline.

Why did a single-zone failure affect so many services?

Google has not given its explanation yet. Common reasons include workloads that run in only one zone, a rush of failover traffic overloading the remaining zones, regional services losing part of their underlying hardware, and databases that cannot fail over without losing recent data. Google also warned that customers could not create new workloads, which slows any recovery that depends on launching new machines.

How can businesses protect themselves from cloud zone outages?

Run critical services across at least two zones, use regional or synchronously replicated databases, and keep spare capacity reserved rather than assuming it can be launched during an incident. For the most important systems, plan a cross-region or cross-provider fallback. Most importantly, regularly rehearse a full zone failure, because untested failover plans tend to fail in exactly the way this outage did.

Will affected customers get compensation from Google?

Cloud SLAs typically offer service credits when availability falls below a promised level, and customers usually have to claim them. Credits rarely cover the business losses an outage causes. Google has not announced any special remedy for this incident. Companies such as banks may face their own obligations to customers, separate from whatever they recover from their cloud provider.