Google Cloud's UK Outage Knocked Out Banks and Courts - Because There's Only One UK Region to Fail Over To

Just after 7:00am BST on Tuesday 20 October 2026, the europe-west2-b availability zone in Google Cloud’s London region lost power. Mains power came back quickly, but according to Google the backup generators failed to engage during the initial outage, and engineers had to drain traffic from the affected cluster while onsite technicians verified power. The two other zones in the region, europe-west2-a and europe-west2-c, did not fully absorb the load, according to engineers managing the incident. Banking apps, the courts’ video platform, delivery networks and public services were among those reported as affected. By 3:52pm, the Ministry of Justice said its systems were still not fully restored.

The detail that turns an infrastructure failure into a lesson for UK businesses is a simple one. europe-west2 is Google’s only UK cloud region. Spreading workloads across the three zones inside it — the standard recommended approach — did not fully protect against this event, and an organisation that wanted to fail over to another region had nowhere to go without leaving the UK. UK Power Networks confirmed that its London electricity systems ran normally throughout, so the failure originated inside Google’s own infrastructure. Google has said most workloads recovered by mid–afternoon and has not yet published its full post–incident analysis. For most small businesses, the exposure is not that they run on Google Cloud directly. It is that their bank, their courier, their website host and their suppliers might.

What happened inside europe-west2

Google Cloud divides each region into availability zones — separate parts of the infrastructure, intended so that a failure in one does not take down the others. The London region, europe-west2, has three: a, b and c. On 20 October, zone b lost power. Google confirmed the root cause: although mains power returned quickly, the backup generators failed to engage during the initial outage. Engineers maintained a frontend and backend drain on the affected cluster while onsite technicians verified backend power functionality.

The reason this became a wider outage, rather than a contained incident, is that the remaining zones did not fully pick up the slack. Engineers managing the incident said europe-west2-a and europe-west2-c did not fully absorb the load from the failed zone, and cited Apigee API gateway services as a particular problem area. Multi–zone deployment is the standard way to make a cloud workload resilient within a region. This event shows that it protects against many failures but not all of them, particularly when shared services within the region come under strain.

Google said the power event was mitigated by 12:27pm, that most workloads had recovered by 2:48pm, and that only a “very small number” of customers were still affected by 3:10pm. In the meantime, UK Power Networks confirmed at 2:59pm that its London systems had run normally throughout, ruling out an external substation fault. Google has not yet published its full post–incident analysis, so questions remain about why the generators did not engage and why the peer zones could not absorb the load.

The breadth of impact was considerable. Organisations named in coverage as affected included banks and fintechs Revolut, Lloyds Bank, HSBC, Barclays, Bank of Scotland, NatWest, Halifax, Nationwide, Emma and Equifax; delivery and retail firms Royal Mail, DPD and Screwfix; property and web services Rightmove, Cloudflare, BT and SiteGround; and public services including NHS England, HM Courts & Tribunals Service and Gov.uk. The courts’ Cloud Video Platform went down across large parts of England and Wales from around 10:00am, and the Criminal Bar Association warned that trials and hearings “cannot proceed”.

That list matters less as a roll–call of who was hit than as an illustration of how far one zone’s power failure reached. Some of those organisations will have been affected directly; others through suppliers, payment providers or web services that sit on Google Cloud. For an ordinary UK business, the most likely experience on 20 October was not “our cloud went down” but “our bank app, our courier tracking and a supplier’s website all stopped working at once” — without any obvious connection between them.

Tuesday 20 October, hour by hour

The timeline below follows the times given in the reporting. All are UK time.

The shape of that day is worth noticing. The power problem began at the start of business hours and was mitigated around lunchtime, but dependent services recovered over the afternoon, and some were still not back near the end of the working day. A provider declaring an incident “mitigated” and a customer’s service working again are different moments, and the gap between them can be hours. Continuity plans that assume a cloud outage ends when the provider says so tend to underestimate how long the disruption actually lasts for the business.

How different architectures fare against a zone failure

The chart below is an indicative planning model — not measured data — ranking common approaches by how well they would have kept a service running through an event like this one.

The fifth bar is the one this incident speaks to most directly. Multi–zone deployment is a real improvement on a single zone, and for most failures it works. But on 20 October the peer zones did not fully absorb the load, and shared services such as API gateways were affected. Organisations that had followed the standard advice still experienced disruption. That does not make multi–zone deployment pointless; it makes it insufficient on its own for services that genuinely cannot stop.

The bottom bar is there because it is a common unspoken assumption. Service credits compensate for an outage after the fact; they do not keep a business running during one, and they are usually small relative to the cost of disruption. Resilience has to come from architecture and planning, not from the contract.

The second bar is the one most within reach of a small business. Most SMEs cannot run their own multi–provider architecture, and most do not need to. What they can do is decide in advance how the business would operate if a key cloud service, or the services of key suppliers, were unavailable for most of a working day — taking orders by phone, keeping a manual record, telling customers through a channel that does not depend on the failed service. That kind of planning would have helped on 20 October regardless of which provider failed.

One zone out of three

The arithmetic of availability zones is the heart of the story.

The design logic of availability zones is that losing one should leave two–thirds of capacity running, with services able to shift onto the survivors. That logic depends on two things holding: that the remaining zones have enough headroom to take the extra work, and that the services a workload relies on are themselves spread across zones in a way that survives the loss. The reporting on 20 October suggests that at least one of those assumptions did not fully hold, with API gateway services cited specifically. Google’s full analysis should clarify which.

For businesses, the practical lesson is that resilience is only as strong as the least resilient thing a service depends on. A workload can be spread across three zones and still fail if a gateway, a database or an authentication service it relies on is not. That is true inside one provider’s region and, by extension, across a business’s whole set of suppliers. The question is not “is our main system resilient?” but “what does it depend on, and are those things resilient too?”

The single–region point sharpens this. Even an organisation that had built everything correctly across three zones had, by definition, no fourth UK option. Its choices for further resilience were another Google region outside the UK, or another provider. Both are legitimate; both involve cost and complexity; and for some organisations, where their data may be held needs careful thought. The point is that this is a decision to make deliberately, before an incident, rather than discover during one.

Where UK businesses are exposed

The rows below reflect where single–provider and single–region risk typically sits for a UK SME, whether through its own systems or through its suppliers, with badges indicating how much attention each usually needs.

The first two rows are where most small businesses actually feel an event like this. A UK SME is unlikely to run its own workloads in europe-west2, but on 20 October many would have found that their bank’s app, a courier’s tracking and some of the web services they rely on were unavailable at the same time. Knowing which of your critical suppliers depend on which providers is hard, and suppliers may not volunteer it. But asking key suppliers how they would continue during a cloud outage is reasonable, and planning how you would operate without them for a day is entirely within your control.

The sixth row is a simple, cheap fix that is often overlooked. If your website, your email and your status updates all depend on one provider, then when it fails you have no way to tell customers what is happening. A basic status page, a social media account, or even a pre–agreed SMS route that sits on different infrastructure means that during an outage you can still say “we know, we’re working on it, here’s what to do” — which is often what customers most need.

What reducing concentration risk costs

The bands below are indicative planning figures for UK businesses reducing their exposure to a single cloud provider or region — not quotes.

The bottom row is the most useful thing a small business can do this week. Most continuity planning is hypothetical. This outage provides a concrete test: what stopped working for you on 20 October, what would have stopped if you had been busier, and what would you do differently? Writing that down while it is fresh produces a more honest plan than any template.

Two ways to depend on the cloud

The right–hand column does not require every small business to build a multi–cloud architecture. For most, the most valuable items are knowledge and planning: knowing what depends on what, and deciding how to operate when it fails. Architecture changes — additional regions, a second provider — are for services where the cost of a day’s outage justifies them. The aim is to make that judgement deliberately, rather than learn the answer during an incident.

Why single–region dependency matters in the UK

The cloud industry has long encouraged customers to think of a region as resilient in itself, because it contains multiple zones. That remains broadly true. But 20 October showed that a single zone failure can still cause widespread disruption, and that when a provider has only one region in a country, region–level resilience means leaving that country. For UK organisations that prefer or need to keep data in the UK, that is a real constraint on how resilient a single–provider design can be.

It is not unique to any one provider. At the turn of the month, an incident that Microsoft linked to its own infrastructure servicing disrupted Azure hybrid connectivity in 18 regions, including both of its UK regions at once. Two UK regions did not help there; one UK region did not help here. The common lesson is that resilience within a single provider has limits that are set by the provider’s own infrastructure and processes — power systems, shared services, maintenance — which customers cannot see or control.

The concentration of the UK’s digital services on a small number of cloud providers is also visible in who was affected. Banks, couriers, retailers, web hosts and public services all reported disruption from a single zone’s power failure. Each of those organisations had its own resilience plans. Collectively, they shared a dependency. That is a systemic point that regulators and large organisations will think about; for a small business, the practical version is that when one major provider has a bad day, many of your suppliers may have one at the same time.

Finally, the human detail is worth remembering. Backup generators that did not engage are a reminder that cloud resilience ultimately rests on physical infrastructure — power, cooling, buildings — maintained by people. Those systems are tested and usually work. When they do not, the consequences are felt far from the data centre, in courtrooms that cannot hold hearings and customers who cannot reach their bank. Planning for that possibility is not pessimism; it is simply accepting that no infrastructure is perfect.

The story at a glance

This story connects to several we have covered recently. The Azure hybrid connectivity outage at the turn of the month hit both of Azure’s UK regions at once — a counterpart to this single–region failure. LINX’s LON2 fabric passing 1Tbps explains why a second path is only worth what its independence from the first is worth. Mastercard’s offline payments rollout is a direct response to the problem of banking and card systems failing at once. The ConnectWise suspension showed how a single supplier’s outage can leave many businesses unable to recover. And the CMA’s proposed designation of Microsoft explores dependency on a single provider from the competition angle.

Frequently asked questions

Cloudswitched

London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.