How One London Data Center Knocked Out Banking Apps: The Google Cloud Outage Explained

A power fault at one Google data center in London took down banking and delivery apps on October 20, 2026. Backup generators did not start, batteries ran out, and servers in one cloud zone lost power. Apps built in only that zone failed, and some multi-zone setups strained as traffic shifted.

This explainer is for anyone who watched their banking app fail and wondered how a single building could matter that much. It covers what a cloud zone is, how backup power is supposed to work, why failover can overload healthy systems, and what you can do as a user. Oddworldz explains how the internet and its machinery work, and outages are a rare window into the hidden physical layer.

What Happened on October 20, 2026

ITPro reports that the problem began just after 7am UK time on October 20 in the europe-west2-b zone, one of three availability zones in London. Online bank Revolut said customers could not make card payments, withdraw cash or make transfers for several hours. Delivery services were also hit.

According to ITPro, Google mitigated the issue at 3pm and services came back about an hour later. By 6pm most customers were restored, with a very small number still affected. Google said it would publish a full analysis after its investigation.

We checked more than one account because the numbers do not match. An incident blog that summarizes Google's preliminary report gives a window of 06:00 to 12:10 UTC, or six hours and ten minutes. ITPro describes roughly eight hours. Different sources count from different starting points and finish lines, so treat the duration as a range for now.

What Is a Cloud Zone, and Why Does It Matter?

A zone is a deployment area for cloud resources inside a larger region. Google's documentation says a region has three or more zones housed in three or more physical data centers. Each zone is treated as a single failure domain, so a zonal outage can affect some or all resources in it.

Think of a region as a neighborhood and each zone as a building with its own power and cooling. If one building loses power, the others should keep running. That promise only holds if what you run is spread across more than one building.

Plenty of apps are not. A company may put a database and its servers in a single zone because it is cheaper and simpler. When that zone fails, everything in it fails together.

Why Did the Backup Power Fail?

Data centers have layers of backup power for exactly this situation. The incident blog summarizing Google's preliminary report says a power-grid disruption hit the facility hosting europe-west2-b. Both the primary and backup programmable logic controllers, the small computers that run the generator switch-over, failed to start the emergency diesel generators.

With no generators, the building ran on uninterruptible power supplies, which are large battery banks. Batteries are designed to bridge a gap of minutes while generators start. When the batteries depleted, hosts, network switches and local storage in that zone went offline.

That is a failure of the switch, not of the generators or the batteries. This is a classic data center problem: the backup system itself needs a backup. Google's final report should say more about why both controllers failed.

Why Did Some Multi-Zone Setups Still Struggle?

Spreading across zones should have saved more customers than it did. According to the incident blog's summary, the physical outage stayed within europe-west2-b. But failover traffic overloaded the other zones, causing higher latency, temporary HTTP 500 and 503 errors, and queuing of new tasks.

Google's preliminary report also said some customers in the other two zones, and some on regional setups, saw impact from demand surges on unaffected capacity and from "synchronous control-plane validation dependencies across zonal boundaries." In plain terms: some of the systems that approve and manage resources still check in across zone lines.

That is a hidden trap. You can run your app in three zones and still depend on a shared management layer that wobbles when one zone dies. Databases built to fail over, such as Cloud SQL and Bigtable, did switch to nearby zones, according to the same summary.

The lesson is about spare room as well. If three buildings share a load and one disappears, the other two must absorb its share instantly. Without headroom, the survivors slow down or fall over too. A sudden surge of demand can break a healthy system even without an attack, as our guide to how DDoS attacks work shows from the other direction.

A quick glossary of outage words

These terms appear in most outage reports, so it helps to know them.

With those five terms, most postmortems become readable. Look for which layer failed first, and whether the backup for that layer was independent or shared.

What Does This Mean for Everyday Users?

Your bank's app is probably built on a major cloud, and so are many delivery, ticketing and payment tools. When a cloud zone fails, many unrelated brands fail together, which can look like a mysterious coincidence. It is the same machinery under different logos.

Our explainer on how one bad setting silenced a DNS service shows a different kind of outage, caused by configuration rather than power. Outages from software changes and outages from physical failures leave similar symptoms but have very different fixes.

A few habits help when a service goes dark.

Most of these failures are not your phone's fault, and no setting on your device will fix a data center. That alone saves a lot of frustration.

What Should Companies Learn From It?

Google's documentation recommends deploying across multiple zones for fault-tolerant applications and using regional resources. For losing an entire region, it recommends a plan for bringing up the application elsewhere and replicating data to another region.

The October 20 incident adds a harder question: do your backups share a hidden dependency? Teams should test failover under load, keep spare capacity and look for control-plane links that cross zone lines. A drill that works on paper may fail when real traffic surges.

The UK's National Cyber Security Centre lists "asset protection and resilience" as one of its cloud security principles, and names service resilience among the mitigations. It is a useful checklist for teams choosing a provider.

Communication matters too. The incident blog notes that the first public update came about 2.5 hours after the start, and the power cause was named about five hours in. Customers can plan around an outage if they know what it is, and silence makes everything worse.

What we still do not know

Careful readers should keep a list of open questions. The preliminary report is not the final word, and several details may change.

At Oddworldz, our editors check each claim against at least two sources before we publish an explainer, and we will point to Google's final analysis when it appears. Our piece on how internet shutdowns work covers another way a whole region can go quiet.

One more practical point: outages like this tend to produce a flurry of guesses on social media within the first hour. Early claims about cyberattacks or software bugs are often wrong. Wait for the provider's own incident report before you repeat a cause.

Conclusion

The London outage is a reminder that the cloud is made of buildings, power and batteries. One failed switch-over in one building took down apps for people who had never heard of the zone.

Keep the caveats in view. The cause comes from a preliminary report summarized by third parties, and the duration varies by source. This article reflects public sources current as of October 28, 2026, and we will treat Google's final analysis as the definitive account once it is out.