Google Cloud London Outage: How a Power Problem at a Single Data Center Brought Banks to a Halt

A power-related outage in Google Cloud's London region simultaneously hit several banks, the fintech app Revolut and a video camera system used in courtrooms. Google apologized and said services were coming back gradually. The incident puts the debate over cloud concentration risk back on the agenda: why were so many different organizations tied to a single physical failure?

What happened?

A power problem in Google Cloud's London region caused widespread disruption to services in the area. Banking apps, Revolut and video infrastructure used in judicial proceedings were affected. Google issued an apology and said recovery work was continuing. There is not yet a detailed final report on the outage's full root cause and duration, so the assessments below are based on early information.

Why did a power problem spread so far?

Cloud providers deliver infrastructure in three layers: the region, the independent availability zones within a region, and the physical data centers in those zones. Zones are normally designed with separate power and cooling lines. One zone going down should not affect the others. Many organizations that trust this architecture believe they have achieved "high availability" once they spread their application across multiple zones within a region.

The catch: if a power failure spreads further than expected, either a shared dependency (a grid connection, a common backup system, the control plane) was in play, or the failure cascaded. From public information alone, we can't say which. But the pattern is familiar: isolation on paper and isolation in practice are not always the same thing.

The second issue is economic. A multi-region architecture roughly multiplies cost and complexity. Data consistency, cross-region latency and failover testing are separate engineering efforts. Many organizations buy "multi-region" support but never try shifting real load to the backup region. When a crisis hits, the backup plan becomes a plan that is being run for the first time.

Comparison with earlier major outages

This incident is not an isolated exception. Different outages have exposed different weaknesses:

The CrowdStrike incident showed us that multi-region is not a cure for every risk: if the same faulty update reached everywhere, geographic distribution was useless. The London incident says the opposite: even when the software is healthy, users are affected all at once when physical infrastructure is concentrated in one spot. Read together, the two incidents lead to a clear conclusion: resilience is not designed with a single measure, but separately against each type of failure.

The regulatory front: What is the UK doing?

The UK has developed a framework to regulate this kind of dependency. Treasury authorities and financial regulators have set up a regime that aims to designate cloud providers heavily used by the financial sector as "critical third parties" and bring them under direct oversight. The logic is this: a bank has to make its own systems auditable, but if the provider it buys services from sits outside oversight, systemic risk stays outside the bank's field of view.

This outage is a concrete example of why the regime is needed. But oversight alone does not prevent outages. The real question is what transparency regulators will demand from providers: the true independence of zones, shared dependencies and the results of recovery tests.

What lessons are there for banks in Türkiye?

In Türkiye, banking regulations are built on keeping critical data and systems within the country. The BDDK's rules on information systems and cloud use emphasize the locality of sensitive data and the bank's right to oversee its provider. This approach makes sense from a data sovereignty standpoint. But when it comes to resilience, it cuts both ways.

The locality rule narrows the choice of providers. If there are only a few regions and data centers inside the country, concentration risk can grow in a way similar to London. In other words, locality can reduce privacy risk while increasing availability risk. The practical takeaway: hybrid setups in which banks combine different domestic providers or on-premises infrastructure may be more resilient than a single-region cloud architecture. That has a cost, but it should be weighed against the cost of an outage.

What's next?

Three developments are worth watching. First, the root cause analysis Google will publish: if it explains how the power failure spread across zones, the real limits of the "zone isolation" promise will become visible. Second, how British regulators use this incident in their critical third party oversight. Third, the organizations' own side: how many banks and public institutions are actually testing failover to a backup region?

Our editorial assessment is this: this incident is less a Google problem than a problem of architectural habit. Providers should document isolation more transparently, but organizations also should not settle for ticking the "multi-region" box. A recovery plan doesn't count as a plan unless it is tested with real traffic at least once a year. An organization that doesn't do this will be the subject of the same headline after the next outage.