On October 20, 2026, Google Cloud's London region (europe-west2) suffered a six-hour disruption that affected UK banking, retail, logistics and public sector services. Google attributed the incident to a power grid disruption at the data center hosting availability zone europe-west2-b, one of the region's three availability zones. It later clarified that this was a third-party (colocation) facility rather than a Google-owned data center.

Google's most recent update says the facility switched to UPS batteries, but both the programmable logic controllers (PLCs) and the backup PLCs failed to transfer the load to the diesel generators. As a result, europe-west2-b's servers, switches and storage went offline when the UPS battery reserves were depleted.

The effects extended beyond services in europe-west2-b. Google reported that some services in other europe-west2 zones also experienced elevated errors and intermittent network issues. It attributed these problems to latency caused by timeouts affecting cross-zone procedure calls and to a surge in redirections and failovers that saturated processing capacity in other availability zones. Google listed 38 affected products.

Google mitigated the fault by isolating europe-west2-b and reported that utility power was restored within an hour. Facility power was then systematically reset, tested and restored, followed by Google Cloud infrastructure and traffic.

Google prioritized the recovery of existing workloads, warning that customers might not immediately be able to create new ones. This indicates constraints on the regional control plane or capacity, in addition to the loss of the zone itself (see Cloud resiliency: plan to lose control of your planes). Google reported that most workloads had recovered by the early afternoon and later said only a "very small number" of customers remained affected.

The incident came exactly one year after the AWS us-east-1 outage of October 20, 2025, which also disrupted UK banks (see AWS outage: what are the lessons for enterprises?).

Organizations and services reported to have been affected include Revolut, Lloyds Bank, HSBC, Barclays, NatWest, Halifax, Nationwide and Equifax in financial services; Royal Mail, DPD and Screwfix in logistics and retail; and NHS England, HM Courts & Tribunals Service and GOV.UK in the public sector.

Not all of those listed have confirmed a link between their disruption and Google Cloud. Revolut has confirmed such a link, and its services remained degraded well beyond Google's own recovery: on the afternoon of October 20, 31 services, including card payments, transfers and account sign-in, were still listed as partially unavailable. Lloyds Banking Group acknowledged disruption, although it did not initially confirm a direct link to Google Cloud. The Ministry of Justice confirmed that its systems had been affected, and a spokesperson said that court systems would not be fully operational until Google Cloud's services were completely back to normal. The courts' Cloud Video Platform was still not fully restored late in the afternoon.

The Financial Conduct Authority is engaging with Google and affected organizations to understand the incident's impact on regulated financial services.

Why were so many affected?

Google has begun a root cause analysis and will make its findings available once it is complete. However, the real question is not why a single data center suffered a power outage, but why other zones were affected and why so many regulated industries were unprepared.

Cloud providers openly advise customers to design applications for the failure of the underlying infrastructure (see Build resilient apps: do not rely solely on cloud infrastructure).

They offer two main mechanisms for building application resiliency:

• Availability zones are physically separate data centers within a region, each with independent power, cooling and networking, connected by low-latency links.
• Regions are geographically separate groups of zones, which protect against the failure of an entire region.

Cloud providers recommend organizations architect applications across zones and/or regions, so that applications continue to operate in the event of a zone or regional outage.

In this case, a single zone initially suffered a power outage, causing all resources in that zone to fail. Although the other two zones generally stayed online, some services in them experienced errors and network issues, and customers could not create new resources.

The major organizations affected would have known it was their responsibility to build resiliency into their applications. So why did they suffer outages? There are several possible explanations:

• Organizations architected their apps to run in a single zone (possible, but unlikely for major firms): The affected applications were hosted in a single zone, which failed. This may explain outages among smaller organizations, but it is unlikely to account for disruption at major regulated firms. Dual-zone resiliency is relatively inexpensive (see Cloud availability comes at a price).
• Organizations settled for dual-zone resiliency because no second region was available (probable): Multi-region deployment was not practical, so multi-zone deployment was deemed good enough. Europe-west2 is Google's only UK region, so firms that had chosen or committed to keeping data in the UK had no second Google UK region to fail over to. Multi-cloud architectures were likely judged too costly and complex.
• Organizations designed multi-zone apps, but Google failed to contain the outage within a single zone (likely): Google reported that the failure spread to other zones through timeouts affecting cross-zone procedure calls and a surge of redirections and failovers that saturated processing capacity. As a result, even correctly designed multi-zone applications may have been disrupted. Google reported that new workloads could not be created, which would have prevented applications from scaling up in the surviving zones. Customers cannot design around these failures within a single region.
• Organizations designed multi-zone apps but did not fully assess their ability to fail over during an outage (probable): Applications were configured across zones, but customer failover did not work as intended. The surviving zones did not fully absorb the load, partly because many customers' failovers occurred at once and saturated their capacity. Possible reasons include too little pre-provisioned capacity in the remaining zones (e.g., using an active-standby or active-passive approach rather than active-active), reliance on scaling up after a failure, hidden zonal dependencies in the customer's own design, or failover that had never been tested under real conditions.

Who is responsible?

It is difficult to place all the blame on Google. Cloud providers clearly state that outages will happen from time to time and that organizations need to assess their own level of risk and design accordingly. Many likely did not design for multi-zonal failure.

For those organizations committed to keeping data in the UK, Google offered no second UK region that could be used to mitigate the outage. However, they did not have to choose Google Cloud for their workloads if they felt it did not provide enough options for resiliency.

For example, Microsoft Azure has two UK regions — UK South and UK West — which could have been used to survive the failure of an entire region, although UK West does not support availability zones. Enterprises could also have kept workloads on premises instead of using the cloud at all, although enterprise data centers suffer outages too.

Uptime Intelligence's analysis of cloud provider status updates shows that, most of the time, the cloud is reliable (see Cloud availability improved in 2025 — but worst cases worsen). But for those organizations unlucky enough to host their applications in a zone or region that does experience an outage, the impact is significant. Europe-west2 itself has a history of facility incidents, including a cooling failure in July 2022 and a loss of power at a network point of presence serving the region in August 2024.

However, in this instance, Google failed to contain the problem. The whole point of availability zones is to prevent failures from propagating between zones. Because the failure spread, customers who followed the provider's own guidance still suffered disruption, and that is where the responsibility shifts toward Google.

Many customers made a reasonable bet on multi-zone resiliency, given how rarely zones fail. But that gamble rested on the assumption that zones are independent and that resources can be rapidly created in other zones during a zone-wide outage. Organizations running critical services in a single region should map their dependencies, test failover under realistic conditions, and assess whether a second region or provider is justified. If a second region is not available, perhaps that cloud provider is not suitable for the workload.