Cloud Run cross-region failover in 2026: survive a full Google Cloud region outage

Summary. On July 21, 2026, Google Cloud moved Cloud Run service health to general availability, which gives multi-region Cloud Run services automatic cross-region failover with no operator action and no extra platform charge. The timing was pointed: six days earlier, on July 15, a power and cooling failure took the europe-west4 (Netherlands) zone offline for 14 hours and 55 minutes. This guide shows the production setup for two regions, the exact gcloud sequence, the real monthly cost (a single global forwarding rule runs about $0.025 per hour, roughly $18 per month, plus $0.008 per GiB of data processed), and the one thing failover does not solve: your database. It is written for CTOs and platform engineers who run serverless workloads on Google Cloud and want an honest picture before they commit an SLA to it.

What Google actually shipped

Cloud Run service health reached general availability on July 21, 2026. During the preview period the feature existed but carried no production guarantee; GA is the point at which you can put it behind an SLA-backed commitment to your own customers. The feature is available in every Cloud Run region and adds no platform charge of its own.

The mechanism is worth understanding before you build on it. Each container instance runs an HTTP readiness probe at a regular interval. Cloud Run aggregates the readiness state of every instance in a regional deployment into a single regional health status. It exposes that status through a serverless network endpoint group (NEG). A global external Application Load Balancer watches the NEGs and steers traffic away from any region whose aggregate health drops, then steers it back when the region recovers. No human runs a script. No DNS record changes.

Two design choices in that description matter. First, failover needs at least two Cloud Run services in different regions; the feature routes between healthy regions, it cannot conjure capacity where none is deployed. Second, the decision is made at the load balancer, not in DNS. Google's global external Application Load Balancer answers on a single anycast IP address, so a failover is a routing change inside Google's network rather than a DNS change that clients must wait to see. That distinction drives most of the behaviour differences later in this guide.

For public websites and APIs, Google recommends Cloud Run with a global external Application Load Balancer. For services that only take internal traffic inside a private network, the equivalent is a cross-region internal Application Load Balancer. The internal path has a different cost profile, covered below.

Why this shipped now: the Netherlands outage

The GA date is not a coincidence. On July 15, 2026, an electrical fault on the utility grid feeding a Google data centre in the Netherlands interrupted power distribution and disabled the cooling plant. Ambient temperatures rose fast enough that Google powered down host servers, storage clusters and network switches to prevent heat damage. The europe-west4 zone was unavailable for 14 hours and 55 minutes, from 16:39 PST on July 15 to 07:34 PST on July 16. Google Cloud VMware Engine, Bare Metal Solution and Google Cloud NetApp Volumes were among the services affected.

The uncomfortable lesson for architects was not that a region can fail. Everyone knows a region can fail. It was that a single data centre inside a zone can fail while the rest of the zone keeps running, and customers often cannot tell which managed services carry that hidden single-facility dependency. Biswajeet Mahapatra, principal analyst at Forrester, put it plainly to The Register: "The real issue is transparency: customers are generally told to use multiple zones and regions for resilience but are rarely given visibility into whether a particular managed service has a single-datacenter dependency within a zone."

That is the gap automated failover is meant to close for the compute tier. If your service runs in two regions and one goes dark, the load balancer stops sending requests there within the health-check window. The value is not magic; it is removing the human from the critical path at 2 a.m.

How the failover works, step by step

Here is the request path once the setup is live, from the outside in.

A user hits the anycast IP. The global external Application Load Balancer terminates the connection and looks up the backend service. The backend service has two serverless NEGs attached, one per region. Each NEG reports the aggregate readiness of its region's Cloud Run instances. The load balancer routes the request to the closest healthy region. If that region's NEG reports unhealthy, the load balancer routes to the other region instead, and keeps doing so until health returns.

The readiness probe is the sensor. You define it on the Cloud Run service, and it should test something real: not just that the process is up, but that the instance can reach its critical dependencies. A probe that returns 200 while the region's database is unreachable is worse than useless, because it tells the load balancer to keep sending traffic into a hole. Point the readiness endpoint at a check that fails when the instance cannot do its job.

Set it up: the production sequence

The build has four stages: deploy to two regions, wrap each region in a serverless NEG, join both NEGs to one global backend service, and put a global forwarding rule in front. The gcloud sequence below uses asia-south1 (Mumbai) and europe-west1 (Belgium) as an example pair. Swap in the regions that match where your users and your data live.

            # 1. Deploy the same container to two regions
gcloud run deploy orders-api \
  --image=asia-south1-docker.pkg.dev/PROJECT/repo/orders-api:latest \
  --region=asia-south1 --allow-unauthenticated

gcloud run deploy orders-api \
  --image=europe-west1-docker.pkg.dev/PROJECT/repo/orders-api:latest \
  --region=europe-west1 --allow-unauthenticated
          

Configure a readiness probe on the service before you wire up the load balancer. In Cloud Run you set the probe in the container configuration (the service YAML) so that Cloud Run can aggregate instance readiness into the regional health the NEG reports. Make the probe hit an endpoint that genuinely verifies the instance can serve, including a fast check of its most important dependency.

            # 2. One serverless NEG per region, each pointing at the service
gcloud compute network-endpoint-groups create neg-asia-south1 \
  --region=asia-south1 \
  --network-endpoint-type=serverless \
  --cloud-run-service=orders-api

gcloud compute network-endpoint-groups create neg-europe-west1 \
  --region=europe-west1 \
  --network-endpoint-type=serverless \
  --cloud-run-service=orders-api
          

            # 3. One global backend service, both NEGs attached
gcloud compute backend-services create orders-backend --global

gcloud compute backend-services add-backend orders-backend --global \
  --network-endpoint-group=neg-asia-south1 \
  --network-endpoint-group-region=asia-south1

gcloud compute backend-services add-backend orders-backend --global \
  --network-endpoint-group=neg-europe-west1 \
  --network-endpoint-group-region=europe-west1
          

            # 4. URL map, target proxy, and one global anycast IP
gcloud compute url-maps create orders-urlmap \
  --default-service=orders-backend --global

gcloud compute target-http-proxies create orders-proxy \
  --url-map=orders-urlmap --global

gcloud compute addresses create orders-ip --global

gcloud compute forwarding-rules create orders-fr --global \
  --target-http-proxy=orders-proxy \
  --address=orders-ip --ports=80
          

The example uses an HTTP proxy to keep the commands short. In production, use a target HTTPS proxy with a Google-managed certificate so traffic is encrypted and you avoid a redirect hop. Point your domain's A record at the global IP that gcloud returns, and you are done: one hostname, one IP, two regions behind it, and failover handled by the load balancer.

To test it, deploy to both regions, then force the readiness probe in one region to fail (for example, by toggling a dependency the probe checks) and watch traffic move to the other region without touching DNS. Rehearse the failback too, because a region that comes back unhealthy and then flaps is its own failure mode.

What it costs

The failover feature is free. The multi-region posture around it is not, and the bill has three parts.

First, the load balancer. A global external Application Load Balancer charges for forwarding rules and for data processing. The first five forwarding rules cost $0.025 per hour combined, and each rule after that is $0.01 per hour. Most services need one rule, so budget about $0.025 per hour, which is roughly $18 per month. Data processing is $0.008 per GiB inbound and $0.008 per GiB outbound, charged in the region where traffic is handled; there is no separate global data-processing fee. Google's own worked example, for the Iowa region with ten forwarding rules and 2,048 GiB of inbound data, comes to $71.13 per month.

Second, the compute. You are now running Cloud Run in two regions instead of one. If you rely on minimum instances to avoid cold starts, you pay for warm instances in both regions, so that line roughly doubles. Request-driven usage still scales to zero where idle, so the increase is concentrated in whatever you keep always-on. There is a small mercy here: with serverless NEG backends behind an external Application Load Balancer, Cloud Run's own outbound data-transfer charges do not apply to requests passed from the load balancer; only internet outbound rates apply.

Third, if your traffic is internal rather than public, the cross-region internal Application Load Balancer prices differently. It bills per proxy instance at $0.025 per hour, and each load balancer is allocated at least three proxy instances even at zero traffic. That is a minimum of $0.075 per hour, about $55 per month, before any data processing or cross-region data-transfer charges. For a private service, the floor is higher than the public path.

The honest read: for a public API already fronted by a load balancer, turning on multi-region failover is a small incremental cost dominated by whatever warm compute you keep in the second region. For a private service, the internal load balancer's three-proxy floor is the number to plan around. If cost control across regions is the wider problem, the same principles that drive cloud cost optimization for Indian companies apply here: pay for warm capacity only where the latency or failover requirement justifies it.

Where failover stops: the data tier

This is the section most launch write-ups skip, and it is the one that decides whether your failover is real. Cloud Run service health fails over the stateless compute tier. It does nothing for your data.

Picture the failure. Region A goes down. The load balancer notices the unhealthy NEG and moves every request to region B in seconds. Region B's Cloud Run instances are healthy and start serving. Now they reach for the database. If your primary database lived in region A, region B is either talking to a cross-region replica or talking to nothing. The compute failed over perfectly and the application still broke.

So the data tier needs its own plan, and its numbers are different from the compute tier's. Cross-region read replicas, on Cloud SQL or similar, use asynchronous replication. Asynchronous means the replica lags the primary, so a failover has a non-zero recovery point objective (RPO): some recent writes can be lost. Typical traditional setups land around 10 to 15 minutes of recovery time objective (RTO) and up to about 5 minutes of acceptable data loss (RPO). Recovering from a regional database failure means promoting a cross-region read replica to primary, a step that is triggered rather than automatic. Reaching RPO near zero and RTO near zero needs synchronous, active-active data architecture, which costs more and is harder to operate.

The practical rule: make the readiness probe fail in a region when that region cannot reach a writable data path. That way the load balancer stops sending writes into a region that cannot serve them, instead of cheerfully routing traffic to compute that is healthy on paper and useless in practice. The hard part of multi-region is not the load balancer. It is monitoring replication lag, keeping a tested promotion runbook, and making sure the application behaves during the transition. Teams that run Kubernetes upgrades and container migrations already know this discipline; the failover story just moves it up to the region level.

How it compares to AWS and Azure

Google is not first to managed multi-region failover; it is arguably last of the three to make it this simple for serverless. The architectures differ in a way that affects failover speed.

AWS commonly does this with Amazon Route 53 health checks in front of Application Load Balancers, using latency-based or failover routing. It works, but DNS-based failover waits on record TTLs and client-side caching, so recovery can lag. AWS Global Accelerator sidesteps that with static anycast IP addresses that route over the AWS backbone to the nearest healthy endpoint, which fails over faster than DNS. A known sharp edge: Route 53 marks an entire ALB unhealthy if any one of its target groups has no healthy target, which can pull a region out more aggressively than intended.

Azure offers Azure Front Door, an application-level anycast service with health probes across regions that can run active-active and accept writes in more than one region for near-zero RTO and RPO, or Azure Traffic Manager for DNS-level routing. Google's new path sits closest to Front Door and Global Accelerator: anycast at the load balancer, not DNS, so failover is a routing change inside Google's network.

If your estate spans more than one cloud, the failover design has to sit inside a wider posture. The same reasoning that shapes an AWS and Google Cloud multicloud cost architecture and a multicloud security posture with AWS Security Hub and Azure applies: each cloud's failover primitive is different, and a portable runbook beats a per-cloud one you only test in the cloud that broke.

India-specific considerations

Google Cloud has two Indian regions, asia-south1 (Mumbai) and asia-south2 (Delhi). A Mumbai plus Delhi pair keeps both compute regions inside India, which matters for latency and for data-residency expectations under the Digital Personal Data Protection Act (DPDP), 2023. If your readiness and data design keep personal data within Indian regions, you get regional resilience without moving data offshore.

Two cautions for Indian deployments. First, an in-country pair protects against a single-region failure but not against a correlated event; if your recovery model needs geographic separation, pairing an Indian region with a distant one changes both your latency budget and your data-residency story, so decide that deliberately. Second, inbound and outbound data processing at $0.008 per GiB is charged per region, and cross-region internal traffic adds transfer cost, so a Mumbai-to-Delhi private path is not free even when it never leaves the country. Teams already working through FinOps moves for Indian cloud teams should fold the second region's warm compute and data-transfer lines into the same budget review rather than treating failover as a line item added later.

A rollout you can defend

Turn on failover in this order. Deploy to a second region and confirm parity. Write a readiness probe that fails when the region cannot reach a writable data path, not just when the process crashes. Attach the serverless NEGs and the global load balancer. Then, before you promise anything to anyone, run a real drill: kill a region's health and watch traffic move, kill the data path and watch the probe pull the region out, and rehearse database promotion end to end with a stopwatch. Write down the RTO and RPO you actually measured, not the ones you hoped for. Those measured numbers are what belongs in your SLA. The load balancer is the easy 20 percent; the drill and the data-tier runbook are the 80 percent that decides whether the failover holds when it counts.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based, senior-led engineering organisation, CMMI Level 5 and ISO 27001:2022 certified, that designs and operates multi-region architectures on Google Cloud, AWS and Azure. We set up Cloud Run cross-region failover with readiness probes that check real dependencies, build the data-tier promotion runbooks that decide whether a failover actually holds, and rehearse the drills so your measured RTO and RPO are the numbers in your SLA. If you want a resilience review or a multi-region rollout, talk to our cloud engineering team.

References

1. Cloud Run Automated Failover Goes GA Six Days After Google's Netherlands Power Cut — TechTimes

1. Automate cross-region failover with Cloud Run service health — Google Cloud Documentation

1. Automate cross-regional failover with service health (tutorial) — Google Cloud Documentation

1. Serve traffic from multiple regions — Cloud Run, Google Cloud Documentation

1. Google adds failover for multi-region Cloud Run services — ITBrief

1. Google Cloud outage after power and cooling failure in Netherlands data center — Data Center Dynamics

1. Google Cloud outage shows it's still hard to understand hyperscalers' real resilience regimes — The Register

1. Cloud Load Balancing pricing — Google Cloud

1. Serverless network endpoint groups overview — Cloud Load Balancing, Google Cloud Documentation

1. Active-active and active-passive failover — Amazon Route 53 Developer Guide

1. About disaster recovery (DR) in Cloud SQL — Google Cloud Documentation

1. Incident details, europe-west4 — Google Cloud Service Health

1. Compare AWS and Azure networking options — Microsoft Learn

_Last updated: July 31, 2026._