One Availability Zone Outage Hit UK Banks and Royal Mail

On 20 October 2026, a single availability zone outage in Google Cloud's London region reportedly hit customers including Lloyds, HSBC, Revolut and Royal Mail. If your campaigns, landing pages or AI features sit in one zone, the same thing can happen to you. This piece covers what happened and what to check on Monday.

What happened in europe-west2-b

From about 06:08 UTC, Google reported a problem in europe-west2-b, one of three zones in its London region. The Register quotes Google's status page: "A power event caused an outage within europe-west2-b zone."

Google's list of affected products included Google Kubernetes Engine, Cloud Run, App Engine, Cloud Filestore, NetApp Volumes, Managed Service for Apache Kafka and BigQuery Data Transfer Service. The Register named Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Screwfix and Revolut as affected customers.

By 14:03 UTC Google said the issue was mitigated for most customers. A very small number were still affected, and some customers might not yet be able to create new workloads.

What an availability zone is, and why one can hurt so many

Google's regions and zones documentation describes a region as an independent geographic area made of three or more zones. It tells you to treat a zone as a single failure domain, meaning everything inside it can fail together. Resources that live in one zone can be affected when that zone has an outage. Regional resources are replicated across zones.

That gap is where outages like this bite. A VM and its disk are zonal: a disk can only attach to a VM in its own zone. So "two VMs behind a load balancer" is one zone with extra steps if both VMs were placed in europe-west2-b.

What Google hasn't said yet

Google said it will publish an analysis once its internal investigation is done. Until then, nobody outside Google knows more than "power event". We don't know why managed services such as Cloud Run and App Engine appeared on the list. We also don't know which customers were running in that zone and which were hit through a dependency. The Register notes that Google's status page was its only source, so treat anything beyond that as a guess.

Check your availability zone exposure on Monday

Marketing teams depend on more of this than they think. Landing pages and form handlers, conversion tracking endpoints, chatbots and personalization models, and the BigQuery Data Transfer Service jobs that pull ad data into dashboards all run somewhere. Ask your engineering team or agency to run these checks, or run them yourself.

Count the zones behind each service

# Which zone is each VM in?
gcloud compute instances list --project=<your-project-id> --format="table(name,zone.basename(),status)"

# Which disks are zonal and which are regional?
gcloud compute disks list --project=<your-project-id> --format="table(name,zone.basename(),region.basename(),type.basename())"

# Are GKE clusters zonal or regional, and which zones do nodes use?
gcloud container clusters list --project=<your-project-id> --format="table(name,location,locations.list())"

A disk with a zone and an empty region is zonal. A cluster whose location is a zone such as europe-west2-b is zonal. Per Google's cluster docs, a zonal cluster has a single control plane in a single zone, while a regional cluster runs control plane replicas in several zones. Even a regional cluster can be configured to run nodes in one zone, so read the locations column too.

Hunt for single-zone dependencies

Disks are the usual culprit. Regional Persistent Disk and Hyperdisk Balanced High Availability replicate synchronously between two zones in a region, which gives you a copy to fail over to.

GPU nodes are the next one. Google's GPU availability page says GPU models vary by region and zone. When I checked, it listed G2 GPUs in europe-west2-a and europe-west2-b but not europe-west2-c. A GPU pool for an AI feature can therefore have only one spare zone, not two. Check the page for the GPU type you actually use.

Subscribe to Google Cloud status alerts

The Google Cloud status page offers an Atom feed at https://status.cloud.google.com/en/feed.atom and a JSON history at https://status.cloud.google.com/incidents.json. Point the feed at the chat channel where campaign owners sit. Personalized Service Health, linked from the same page, shows incidents affecting your own projects.

Then agree who pauses paid campaigns when the page they point to is down. Spend keeps running when the landing page doesn't.

Caveats

• Spreading across zones does not cover losing a whole region. Google treats that as a separate disaster recovery plan.
• If you spread across three zones, the surviving two need enough capacity to carry the load. Test it before an outage does.

A zone is a failure domain, and if your production stack, AI features included, has one, the next power event will find it.