Google Cloud Outage europe-west2: What Failed and How to Build Multi-Zone Failover

On 20 October 2026 a single availability zone in Google’s London region stopped working, and a surprising share of UK digital life stopped with it. Banks, a postal service, a telecom operator, a property portal and a parcel carrier all reported trouble, even though the region still had two healthy zones. That is the uncomfortable lesson of this Google Cloud outage europe-west2: “we run in three zones” is a marketing sentence until you have proved that the architecture behind it survives losing one.

The event matters now because regulators, boards and customers increasingly treat cloud concentration as an operational-resilience question rather than a procurement detail. A power event in one building is a normal, designed-for failure class. What turned it into an eight-hour incident for many workloads was not the electrons; it was how applications, control planes and dependencies were wired.

You will leave with a precise timeline of what is publicly known, a mechanism-level explanation of why a zonal failure cascades, and a concrete multi-zone design for Google Kubernetes Engine (GKE) and Cloud Run, including manifests, health-check logic and an RTO/RPO table you can adapt.

What this covers: the verified incident facts, the zonal-versus-regional anatomy of the failure, a reference multi-zone architecture, runnable Kubernetes and Terraform examples, failure modes that still bite, and a checklist.

Source discipline. Everything attributed to the incident below comes from reporting that quotes Google’s status page (chiefly The Register’s coverage of 20 October 2026). Google said it would publish an analysis after its internal investigation; at the time of writing I could not verify that a final post-incident report was available, so root-cause detail beyond “power event” is deliberately not asserted. Third-party figures are labelled as estimates.

Context and Background

Google Cloud organises capacity into regions, and each region into zones. A zone is a deployment area within a region that Google designs to be a separate failure domain for power, cooling and networking, and europe-west2 is the London region with three zones: europe-west2-a, -b and -c. The public promise is that a well-architected application spread across zones should tolerate the loss of one. Regional services such as regional Cloud Storage buckets, regional GKE clusters and multi-zone managed instance groups are marketed on exactly that promise.

The reality is that “zone” is a failure-domain boundary for hardware, not for your architecture. Applications fail across that boundary through shared control planes, single-zone data stores, hard-coded zonal endpoints, zonal persistent disks, and the human tendency to deploy the first working configuration and move on. Every major hyperscaler has had a comparable event: single-building power or cooling problems have taken down zones at several providers in recent years, and each time the pattern of customer impact looks similar.

For readers who have followed this site’s coverage of resilience, the theme is familiar. Our guide to multi-region active-active database architecture covers the state-replication side of the problem, and our piece on incident management architecture, severity levels and blameless postmortems covers the organisational side. This post sits between them: the compute and traffic layer inside one region, where most teams actually live.

Google’s own guidance frames this clearly. The Google Cloud Architecture Framework reliability pillar and the “Geography and regions” documentation describe zones as isolated failure domains and recommend deploying across multiple zones for high availability, and across regions for disaster recovery. Those documents are the right primary sources for the design guidance below, and they are worth reading end to end: Google Cloud geography and regions lists the zones, and the Architecture Framework reliability pillar sets out the patterns.

Why the London region matters

London is one of the densest financial-services locations in the world, and the UK’s regulators have spent years pushing firms to map their important business services to the technology that supports them. The Bank of England, the Prudential Regulation Authority and the Financial Conduct Authority published operational-resilience rules requiring firms to stay within defined impact tolerances for important business services. The EU’s Digital Operational Resilience Act (DORA) applies similar thinking in Europe, and the UK has a regime for designating critical third parties. How exactly this specific incident interacts with those regimes is something supervisors, not bloggers, will determine, so treat the regulatory commentary later in this post as analysis rather than fact.

What We Know About the Outage

The following timeline is assembled from The Register’s report, which quotes Google’s status page. Times are UTC.

Time (UTC, 20 Oct 2026)	Event
06:08	Outage begins in `europe-west2-b`, one of three zones in the London region
Early	Google status page: “A power event caused an outage within europe-west2-b zone”
11:58	Status page says full recovery of workloads should be “completed, tentatively” by 13:00
Before 14:03	Existing workloads prioritised for recovery; creation of new workloads may still fail
14:03	Google reports issue mitigated for most customers; a very small number still affected
After	Google says no further status-page updates; analysis to follow internal investigation

Services named as affected in the coverage were BigQuery Data Transfer Service, Cloud Filestore, Cloud Run, Google App Engine, Google Cloud NetApp Volumes, Google Kubernetes Engine and Managed Service for Apache Kafka. An expert quoted by The Register estimated that 38 services were affected in total; an analysis site, FourWeekMBA, repeats the 38-product figure. Treat that number as an outside estimate, not a Google statement. Another outlet’s headline cites 171 possibly affected services via status-aggregation data; I could not open that page and I do not rely on it.

Customers reported as affected include Lloyds Bank, HSBC, Royal Mail, Rightmove, DPD, BT, Screwfix and Revolut. Reported impact is not the same as an outage of each firm’s entire platform: the public record shows that customers saw disruption, not how much of each service was down or for how long. Keele University’s Dr Amro Al-Said Ahmad was quoted saying the incident showed how failure in one cloud region can cascade into dependent applications and third-party services, and that resilience needs multi-region deployment, portability and tested disaster recovery.

Duration is worth stating carefully. The first symptom is dated 06:08 UTC and Google reported mitigation for most customers at 14:03 UTC, roughly eight hours. That is the platform-side window; for any given customer, recovery depended on whether their workloads restarted cleanly, which is a different clock.

Anatomy of a Zonal Failure: Why One Zone Became a Wide Incident

A single-zone power failure becomes a multi-service incident because many cloud services have zonal data planes, zonal state, or control-plane operations that must run in the failed zone. Surviving requires that every layer, compute, state, networking and the deployment pipeline, can operate with one zone missing.

Figure 1: How a power event in one zone propagates. The failed zone removes compute, zonal disks and zonal endpoints; capacity pressure and control-plane operations then hit the surviving zones.

Figure 1 shows the shape of the cascade. The failed zone removes three things at once: the compute running there, any state that lives only there, and any control-plane component that was homed there. The surviving zones then absorb rescheduled and retried load while some operations, such as creating new workloads, may be degraded.

Layer 1: capacity and the thundering herd

When a zone disappears, every autoscaler and scheduler in the region tries to replace its capacity in the other two. If you ran at 70 percent utilisation in each of three zones, losing one leaves 2 zones holding 105 percent of the original steady-state load. That is arithmetic, not a measurement from this event: 3 zones at 70 percent equals 2.1 zone-units of work; two zones can hold 2.0. You are already over capacity before a single retry storm arrives.

The standard rule is N+1 at the zone level. With three zones, each zone must run at no more than about 66 percent of its capacity so two can carry the whole load; with two zones, each must stay under 50 percent. Many teams discover during an incident that their autoscaler maximums, quotas, or the provider’s available machine inventory do not allow the burst. Google reported that existing workloads were prioritised while new workload creation could fail, which is precisely the situation in which quota and pre-provisioned headroom decide who recovers.

Layer 2: zonal state

Persistent disks attached to a VM are zonal; a regional persistent disk replicates across two zones within a region, at higher cost and some write-latency penalty. Filestore and NetApp Volumes instances are tied to zones or regions depending on tier. Both Cloud Filestore and Google Cloud NetApp Volumes appear in the affected list, which is consistent with, though not proof of, zonal storage dependencies. Any StatefulSet whose PersistentVolumeClaims bind to zonal disks cannot simply reschedule into another zone, because the volume is not there.

This is the layer where “multi-zone” most often turns out to mean “multi-zone stateless tier in front of a single-zone database.” The fix is replication at the data layer, not the compute layer, and it is where RPO (recovery point objective) is decided.

Layer 3: control-plane dependencies

A managed Kubernetes control plane in a zonal cluster lives in one zone; a regional cluster replicates it across three. While the data plane can keep serving existing pods when the control plane is unavailable, any operation that needs the API server, such as scaling, rescheduling or deploying a fix, stalls. The same applies to your own tooling: CI runners, artifact registries, secret stores, service meshes and feature-flag services that are zonal or sit behind a single zonal endpoint can leave you unable to repair the thing you need to repair.

The cruel version is circular dependency: your failover automation lives in the zone that failed. I come back to this in the failure-modes section.

Layer 4: third-party and downstream dependencies

Royal Mail, DPD and BT appearing in the affected list suggests dependency chains rather than only direct customers: one company’s SaaS provider, payment processor, identity provider or API gateway may itself be hosted in the failed zone. This is inference from the customer list; the public record does not say which firm used which service. But it is the right mental model: your availability is the product of your own architecture and that of every dependency on your critical path, and the weakest dependency is usually one you did not know you had.

Zonal, regional and global services

A useful mental sort for every component you run:

Zonal resources: Compute Engine VMs, zonal persistent disks, zonal GKE clusters, single-zone Filestore. Lose the zone, lose the resource until it returns.
Regional resources: regional GKE clusters, regional persistent disks, regional managed instance groups, regional load-balancer backends, Cloud Run services (which are regional and deploy across zones). These should survive a zone loss if configured and if capacity exists.
Multi-regional or global: global external load balancers, multi-region Cloud Storage buckets, Spanner multi-region configurations. These survive a region loss when used correctly.

Cloud Run appearing among the affected services illustrates that “regional” does not mean “immune.” Even a service documented as spreading across zones may have degraded capacity, slower instance starts, or degraded dependent subsystems during a zone failure. The honest position: I do not know the internal mechanism for each affected Google service and Google had not yet published one.

A Reference Multi-Zone Architecture on Google Cloud

A resilient single-region design spreads stateless compute across three zones with headroom for N+1, puts a regional or global load balancer with health checks in front, and replicates state synchronously across at least two zones. A second region, tested regularly, is the answer to events bigger than one zone.

Figure 2: Reference design. A global load balancer fronts a regional GKE cluster spread over three zones, with a synchronously replicated database and a warm standby region for regional events.

The design in Figure 2 has five decisions worth defending individually.

Decision 1: regional clusters, not zonal clusters

On GKE, choose a regional cluster. The control plane is replicated across three zones and node pools can be spread across them. A zonal cluster is cheaper and simpler, and it is the correct choice for a development environment; it is the wrong choice for anything a bank, retailer or logistics firm depends on. Google lists GKE among the services affected on 20 October; whether a given customer’s cluster was zonal or regional determines whether the outcome was a brief pod reschedule or an outage of the control plane itself. That specific detail is not in the public reporting.

Decision 2: spread pods by topology, not by hope

Kubernetes will happily place all replicas of a Deployment on nodes in one zone if that is where capacity is. Topology spread constraints with topologyKey: topology.kubernetes.io/zone enforce an even distribution, and whenUnsatisfiable: DoNotSchedule makes the constraint hard. Pair them with PodDisruptionBudgets so voluntary disruptions, such as node upgrades, cannot remove too many replicas together.

Decision 3: size for N+1

With three zones, running each zone at 66 percent or less of capacity is the break-even for surviving a zone loss without degraded service. Teams often resist this because it looks like paying for 50 percent idle capacity. The alternative is to accept degraded service by design and shed load deliberately, which is a legitimate choice if you decide it in advance, tier your traffic, and test the shedding. What is not legitimate is to discover it at 06:08 UTC.

Decision 4: replicate state across zones synchronously

Use managed databases in a high-availability configuration: Cloud SQL high availability places a standby in a different zone of the same region with synchronous replication; AlloyDB offers a regional high-availability option; Spanner regional configurations replicate across three zones. Each of these gives near-zero RPO and an RTO bounded by failover detection and promotion, at the price of cross-zone write latency. Verify the exact guarantees of each product in current Google documentation before committing a number to a runbook; the figures in the table below are design targets, not vendor guarantees.

Decision 5: put a second region behind a second failure domain

A zone failure is the common event. A regional failure is rarer and larger. The two need different mechanisms: multi-zone design is mostly automatic and sub-minute; multi-region failover is usually a deliberate decision with data-lag implications. Our multi-region active-active database architecture guide goes through the consistency trade-offs of that second step.

RTO and RPO by design tier

The table gives illustrative design targets, not measurements and not Google commitments. RTO is recovery time objective, the time to restore service; RPO is recovery point objective, the data you are prepared to lose.

Tier	Compute	State	Typical RTO target	Typical RPO target	Relative cost
0. Single zone	Zonal cluster, zonal VMs	Zonal disk	Hours, until zone returns	Up to last backup	1.0x
1. Multi-zone, no headroom	Regional cluster	Regional or HA database	Minutes, degraded	Near zero	about 1.2x
2. Multi-zone with N+1 headroom	Regional cluster at 66 percent per zone	HA database, tested failover	Under a minute to a few minutes	Near zero	about 1.5x
3. Warm standby region	Tier 2 plus smaller second region	Async cross-region replica	15 to 60 minutes	Seconds to minutes	about 2x
4. Active-active multi-region	Full capacity in two or more regions	Multi-region database	Seconds	Near zero to seconds	2x to 3x

The relative-cost column is a rough planning heuristic, not a quote; your actual multiplier depends on committed-use discounts, data egress and which components you duplicate.

Deeper Analysis: Building and Testing the Failover Path

Architecture diagrams do not fail over; configuration does. This section walks through the pieces that actually decide the outcome and the sequence of events when a zone drops.

Figure 3: Failover sequence. Health checks mark the zone’s backends unhealthy, the load balancer drains traffic to remaining zones, the autoscaler adds capacity, and the database promotes its standby.

The timing budget of a zone failover

Figure 3 shows what happens in order. Each step has a configurable interval, and the sum is your real RTO for stateless traffic. A typical Google Cloud load balancer health check is configured with a check interval, a timeout, an unhealthy threshold and a healthy threshold. If you set a 5 second interval and an unhealthy threshold of 3, detection takes about 15 seconds. Add connection draining, retries by clients, and DNS or client-side caching behaviour, and an end-to-end switchover in the tens of seconds to low minutes is realistic. Those numbers follow from the parameters you choose; they are not a benchmark. Measure your own.

For stateful promotion, Cloud SQL HA failover and similar mechanisms involve failure detection, standby promotion and connection re-establishment, usually reported by Google in documentation as taking on the order of a minute or more. Check the current documentation for your engine, and then measure, because application connection-pool behaviour often dominates the database’s own number. A pool that holds dead connections for five minutes turns a 60-second database failover into a five-minute outage.

Kubernetes: spreading and protecting replicas

This Deployment spreads three or more replicas evenly across zones, keeps a PodDisruptionBudget so upgrades cannot take out too many at once, and uses readiness probes so the load balancer sends traffic only to pods that can serve.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payments-api
spec:
  replicas: 6
  selector:
    matchLabels:
      app: payments-api
  template:
    metadata:
      labels:
        app: payments-api
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: payments-api
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: payments-api
      containers:
        - name: api
          image: europe-west2-docker.pkg.dev/PROJECT/apps/payments-api:1.0.0
          resources:
            requests:
              cpu: "500m"
              memory: 512Mi
          readinessProbe:
            httpGet:
              path: /healthz/ready
              port: 8080
            periodSeconds: 5
            failureThreshold: 2
          livenessProbe:
            httpGet:
              path: /healthz/live
              port: 8080
            periodSeconds: 10
            failureThreshold: 3
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: payments-api-pdb
spec:
  maxUnavailable: 1
  selector:
    matchLabels:
      app: payments-api

Two details matter here. First, DoNotSchedule on the zone constraint means that if a zone is lost and pods are rescheduled, the scheduler will refuse to pile all replicas into the surviving zones if the skew would exceed one among available zones; because skew is computed over the zones that currently have eligible nodes, the surviving two zones can still be balanced, but you must ensure your node pools can scale to hold them. Second, a hard zone constraint combined with insufficient capacity leaves pods Pending, which is a failure you can see and alert on, as opposed to silently concentrated risk.

Autoscaling that can absorb the loss

Set the cluster autoscaler or GKE node auto-provisioning with maximums large enough to hold the full load in two zones, and confirm Compute Engine quota in that region matches. Quotas are regional; if your quota is sized for steady state, a zone failure can hit a quota wall precisely when you need to scale. Raise quota proactively and confirm machine-type availability in the surviving zones, since the provider’s capacity pressure during a regional event is not under your control. Reserved capacity or committed-use reservations are the only way to convert “probably available” into “ours”.

A horizontal pod autoscaler on CPU or a request-rate metric then adds pods; pair it with a minimum replica count equal to what you need to survive a zone loss before the autoscaler reacts. In the example above, 6 replicas across 3 zones is 2 per zone; losing one leaves 4, which is 67 percent of the original, so you should size the baseline so that 4 replicas can carry peak. Otherwise, set the minimum to 9.

Terraform: a regional cluster with node pools in three zones

resource "google_container_cluster" "primary" {
  name     = "prod-london"
  location = "europe-west2"          # regional cluster: control plane in 3 zones
  remove_default_node_pool = true
  initial_node_count       = 1
}

resource "google_container_node_pool" "general" {
  name       = "general"
  cluster    = google_container_cluster.primary.name
  location   = "europe-west2"
  node_locations = [
    "europe-west2-a",
    "europe-west2-b",
    "europe-west2-c",
  ]

  autoscaling {
    total_min_node_count = 6
    total_max_node_count = 60
    location_policy      = "BALANCED"
  }

  node_config {
    machine_type = "e2-standard-4"
  }
}

With location = "europe-west2" the cluster is regional. node_locations pins the zones, and location_policy = "BALANCED" asks the autoscaler to keep nodes spread across zones. Confirm argument names against the current Terraform provider documentation for your version, since GKE node-pool autoscaling fields have changed across provider releases.

Cloud Run and serverless

Cloud Run services are regional. Google deploys instances across zones in the region, and a zone failure should shift traffic to instances elsewhere, but Cloud Run was named as affected on 20 October. The correct inference is not that serverless is fragile; it is that a managed service’s multi-zone behaviour is a property you must test, not assume. For serverless workloads, the practical levers are: set a nonzero minimum instance count so a cold start storm does not coincide with the failure; deploy the same service to a second region; and front both with a global external Application Load Balancer using serverless network endpoint groups, so the load balancer fails over between regions automatically.

Health checks that tell the truth

A health check that returns 200 whenever the process is alive will keep sending traffic to a pod whose database is unreachable. Separate liveness (is the process wedged?) from readiness (can it serve traffic right now?). A readiness endpoint should verify the hot-path dependencies with tight timeouts, but not every dependency, or one flaky optional service drains the entire fleet. This is the cascading-failure trap: readiness that depends on a shared downstream can mark every replica unready simultaneously and convert a partial failure into a total one.

# Readiness handler sketch: check only what the request path cannot live without
import time

def ready(db, cache, deadline_ms=200):
    start = time.monotonic()
    ok_db = db.ping(timeout=deadline_ms / 1000)
    # cache is optional: degrade, do not fail readiness
    ok_cache = cache.ping(timeout=0.05)
    elapsed = (time.monotonic() - start) * 1000
    if not ok_db:
        return 503, {"db": False, "ms": elapsed}
    return 200, {"db": True, "cache": ok_cache, "ms": elapsed}

Game days: the only proof

You cannot demonstrate zone resilience by reading a diagram. A game day removes a zone from service on purpose, in a pre-production environment that mirrors production and then, once you are confident, in production during a quiet window. Cordon and drain all nodes in one zone, fail the primary database over, block the zone’s backends at the load balancer, and watch what breaks. Record time to detect, time to mitigate, and every manual step. The fastest improvement comes from eliminating manual steps that require a human to be awake and to have credentials that live in the failed zone.

Trade-offs, Gotchas, and What Goes Wrong

Figure 4: Common failure modes that persist even in multi-zone designs: shared control plane, quota walls, hidden zonal dependencies, retry storms and manual runbooks.

Multi-zone design is necessary and insufficient. Figure 4 groups the ways it still goes wrong.

Hidden zonal dependencies. A single zonal Redis instance, a self-managed Kafka broker set in one zone, an NFS mount, a license server or a scheduled job runner can silently be the one thing everything needs. Managed Service for Apache Kafka appearing among affected services is a reminder that managed offerings have their own zone topology; check how the product places brokers and what its documentation promises. Inventory every stateful component and label it zonal, regional or global. Anything labelled zonal on the critical path is a finding.

Retry storms. When a dependency fails, clients retry. If every client retries immediately and without limit, the recovering system faces a multiple of normal load and falls over again. Use exponential backoff with jitter, retry budgets, and circuit breakers. Recovery is often the most dangerous phase of an incident, and the eight-hour window on 20 October included an extended recovery period during which Google prioritised existing workloads.

Capacity is not guaranteed. The statement that new workloads might not be creatable is a reminder that the cloud’s elasticity has a ceiling during regional stress. Everyone in the region is trying to scale at once. Pre-provisioned capacity, reservations and N+1 headroom are what let you avoid competing for scarce capacity with your neighbours.

Failover automation in the failure domain. If your deployment pipeline, runbook wiki, identity provider or paging system runs in the zone that failed, you may lose the tools needed to respond. Keep the break-glass path independent: out-of-band access, credentials not held in the failing zone, a status page hosted elsewhere, and a communications channel that does not depend on your own platform.

Cost. N+1 headroom, regional disks and standby regions cost real money, often 1.2x to 2x baseline, as in the table above. The decision is not whether to pay but which services deserve which tier. A tiered service catalogue, with a payments path at Tier 2 or 3 and an internal reporting job at Tier 0, spends the budget where an outage actually hurts.

Consistency versus availability. Synchronous cross-zone replication adds latency to every write; asynchronous replication across regions risks losing recent writes at failover. There is no free option, and choosing is a business decision about acceptable data loss.

False confidence from the SLA. A service level agreement is a financial remedy, not an engineering guarantee. Credits for downtime do not cover lost customer trust, regulatory consequences or a branch queue. Read the SLA to understand what configuration it assumes, since regional and multi-zone availability commitments usually apply only to correctly configured deployments, then engineer to your own objectives.

The regional-event blind spot. Everything above handles one zone. If the root cause were a regional network or control-plane fault, multi-zone would not help. Without a published analysis, I cannot say this event was anything other than zonal as Google described, but you should not assume zones are your only failure domain.

The regulatory angle for UK banks (analysis, not verified fact)

UK banks and other regulated firms are subject to operational-resilience rules that require them to identify important business services, set impact tolerances and show they can remain within tolerance in severe but plausible scenarios. The loss of a single availability zone at a major cloud provider is such a scenario, and the customer list in the reporting is dominated by regulated and critical-infrastructure-adjacent firms. My reading, labelled as unverified: supervisors are likely to ask whether firms had mapped dependencies on europe-west2-b, whether they had tested failover, and whether impact tolerances were met. I have not seen any regulator statement on this incident and nothing here should be read as describing any particular firm’s compliance. The same logic applies under DORA to firms serving EU customers, which expects tested ICT business continuity and exit planning.

Practical Recommendations

Start with an inventory rather than a rewrite. For each production service, record where its compute, state, control plane and tooling live, and label each component zonal, regional or global. This single spreadsheet usually surfaces more risk than any tool, and it gives you the evidence to argue for budget.

Then tier your services. Decide which business services must survive a zone loss within a minute, which can tolerate a degraded mode, and which may be down until the zone returns. Spend on the first group: regional clusters, N+1 sizing, HA databases and a tested standby region. Explicitly accept risk on the third group in writing, so nobody is surprised.

Finally, rehearse. A failover you have not executed is a hypothesis. Run a zone-drain game day each quarter, measure time to detect and recover, fix the manual steps, and feed what you learn into your incident process; our incident management architecture guide covers how to turn those findings into error-budget policy. If you run Kubernetes on more than one cloud, compare how each provider handles zones and upgrades in our managed Kubernetes comparison of EKS, GKE and AKS.

Checklist

[ ] Every critical-path component labelled zonal, regional or global.
[ ] GKE clusters regional; node pools spread across all three zones.
[ ] Topology spread constraints and PodDisruptionBudgets on every critical Deployment.
[ ] Zone-level N+1 headroom: each zone at or below about 66 percent of capacity.
[ ] Regional quota and reservations sized for a two-zone steady state.
[ ] Databases in HA mode with a tested, timed failover and sane connection-pool timeouts.
[ ] Readiness checks verify hot-path dependencies only; retries use backoff, jitter and budgets.
[ ] Deployment, secrets, identity and paging do not depend on a single zone.
[ ] Second region warm and tested for the services that need it.
[ ] Quarterly zone-drain game day with recorded detect and recover times.
[ ] Customer communication path independent of your own platform.

Frequently Asked Questions

What caused the Google Cloud outage in europe-west2 on 20 October 2026?

Google’s status page, as reported by The Register, said “A power event caused an outage within europe-west2-b zone.” The problem began around 06:08 UTC. Google had said it would release an analysis after its internal investigation, and I could not verify that a final report had been published, so deeper root-cause details such as the specific electrical or cooling component are not known publicly at the time of writing.

How long did the europe-west2-b outage last?

The first symptoms were reported at about 06:08 UTC, and at 14:03 UTC Google said the issue was mitigated for most customers, with normal service resumed for the majority and a very small number still affected. That is roughly eight hours of platform-side impact. Individual customers could see shorter or longer disruption depending on their architecture and how cleanly their workloads restarted.

Why did a single-zone failure affect so many services?

Many services, including managed ones, have zonal components: data planes, storage, or control-plane operations. Coverage named BigQuery Data Transfer Service, Cloud Run, GKE, App Engine, Filestore, NetApp Volumes and Managed Service for Apache Kafka as affected, and an expert estimated 38 services in total. Customers also depend on third parties hosted in the same zone, so impact spreads through dependency chains.

Is multi-zone enough, or do I need multi-region?

Multi-zone handles the common event, the loss of one building or zone, and can be automatic and fast. Multi-region handles rarer regional failures and costs more in complexity, data-replication trade-offs and money. Most services should be multi-zone with headroom; only business-critical services justify warm or active-active multi-region. Decide per service using impact tolerance and cost, then test the choice.

How much spare capacity do I need to survive a zone failure?

With three zones, each zone should run at no more than about 66 percent of its capacity so that the remaining two can carry the full load. With two zones the figure is 50 percent. This is arithmetic, not a vendor rule. You also need regional quota and machine availability in the surviving zones, which reservations help secure.

Do regional GKE clusters survive a zone outage?

A regional GKE cluster replicates its control plane across three zones and can spread nodes across them, so the cluster API should remain available if one zone is lost, provided your workloads are spread with topology constraints and your stateful volumes are replicated or regional. A zonal cluster does not have this property. Always test, since persistent volumes and add-ons can still tie you to one zone.