Cloud Run Automated Failover Is GA: Enable It Now

Google’s Netherlands data center lost power for nearly 15 hours on July 15. Six days later, Cloud Run automated failover went Generally Available. Timing aside, the feature that serverless developers have needed since Cloud Run launched is finally here — and it doesn’t cost extra beyond what you’re already paying.

What Was Broken Before

Multi-region Cloud Run deployments looked good on paper but had a structural problem. If you deployed to us-central1 and europe-west1, traffic routed to the geographically closest region. That’s it. If the close region’s service started failing, traffic kept going there. The global load balancer had no signal from Cloud Run to act on — because Cloud Run wasn’t exposing one.

Developers who wanted real failover had to build it themselves: custom health polling endpoints, manual traffic weight adjustments, or complex third-party setups. None of it was elegant. For a managed serverless platform competing against AWS Lambda and Azure Container Apps, this was a conspicuous gap. The Netherlands outage made it impossible to ignore.

How Service Health Works

The GA feature adds a health layer between your Cloud Run services and the load balancer. Three components work together:

• Readiness probes: Cloud Run periodically sends HTTP checks to each container instance — a path like /healthz that returns 200 when healthy. Cloud Run aggregates these results across all instances in a region to determine overall regional health.
• Serverless NEGs: Network Endpoint Groups bridge the load balancer and Cloud Run. A service-health-enabled NEG also exposes regional health status back to the load balancer — something a plain serverless NEG doesn’t do.
• Global Application Load Balancer: When the ALB sees a regional NEG report unhealthy, it stops sending traffic there and reroutes to a healthy region. When the failing region recovers, traffic is gradually restored with no manual intervention.

This is available for public-facing services via a global external ALB, and for private workloads via a cross-region internal ALB. Full architecture details are in the official Cloud Run service health documentation.

Setting It Up

Google’s “two clicks” framing is marketing. The actual setup has three steps, though the gcloud CLI makes each one straightforward.

Step 1: Deploy to multiple regions with a readiness probe

gcloud beta run deploy my-service \
  --source=. \
  --regions=us-central1,europe-west1 \
  --min=1 \
  --readiness-probe httpGet.path="/healthz"

Your app needs to serve a /healthz endpoint returning 200 when healthy. A minimal implementation:

# Python (Flask)
@app.route("/healthz")
def healthz():
    return "ok", 200

Step 2: Create serverless NEGs for each region

gcloud compute network-endpoint-groups create my-neg-us \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --cloud-run-service=my-service

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

Step 3: Set up a global external Application Load Balancer with both NEGs as backends. Google’s full tutorial walks through this — it involves creating a backend service, health check, URL map, and frontend. A dozen gcloud commands in total, not two clicks, but all well-documented.

The Cost You’re Not Seeing

Google says no extra charge for the feature. That’s accurate and slightly misleading. Readiness probes require at least one minimum instance per region — you’re no longer scaling to zero.

For a two-region deployment, you’re always paying for at least two running instances. If your service is low-traffic or experimental, that flips the economics of serverless. If it’s production traffic with real SLAs, it’s probably already worth it — you shouldn’t be relying on cold starts for production anyway. This feature is designed for production workloads, not hobby projects. Be clear-eyed about what “free feature” actually means here.

If You Already Have Multi-Region Cloud Run

Existing multi-region deployments that rely on geographic routing alone — no readiness probes, no service-health-enabled NEGs — are not automatically failing over. They’re routing by proximity. Your service can be failing in the nearest region and traffic will keep going there.

If your Cloud Run setup was deployed before this GA, you need to add readiness probes and rebuild your NEGs with service health enabled. Check your current setup before assuming you have the resilience you think you have. The Register’s post-outage analysis on hyperscaler resilience transparency is worth reading alongside Google’s documentation.

Bottom Line

Cloud Run automated failover GA is the right move, and it arrived at the right moment. Geographic routing without health signals is not multi-region resilience — it’s just multi-region deployment. Now there’s a native fix.

If you’re running Cloud Run in production across multiple regions, enabling service health should be on your list this week. Factor in the minimum instance cost. Budget an hour for the ALB setup if you don’t already have one. The failover itself, once configured, is automatic and free.