PSC Seamless Failover: An Overview of Private Service Connect Health (Preview)
In the world of cloud networking, maintaining high availability across regions is a top priority. Google Cloud has introduced Private Service Connect (PSC) health in preview, a feature designed to give service producers more control over how their services signal health to consumers.
What is it?
PSC health is a monitoring framework that allows service producers to define and communicate the “health state” of their regional services directly to consumer load balancers. Unlike standard health checks that look at individual VMs, PSC health uses composite health checks to aggregate the status of multiple backends into a single signal. This signal is then automatically propagated to the consumer’s load balancer.
Screenshot 2026-02-09 13.46.241529×990 100 KB
What problem is it solving?
Previously, consumer load balancers often relied on outlier detection to decide when to fail over to another region. Outlier detection is reactive—it infers a service is down based on 5xx errors or connection timeouts.
PSC health solves two major issues:
-
Reactive vs. Proactive Failover: It replaces “best-guess” outlier detection with an explicit health signal from the producer.
-
Granular Control: Service producers can now define exactly what “healthy” means (e.g., “at least 60% of my instances must be up”) before the consumer’s traffic is rerouted. This prevents “partial failures” from causing unnecessary or erratic traffic shifts.
Why is it important?
The primary value of PSC health is reliability at scale. For mission-critical applications, every second of downtime matters. By providing an automated, cross-region failover mechanism triggered by actual service health:
-
Failover is faster: Traffic is rerouted the moment the producer’s health threshold is crossed.
-
Reduced Latency: Consumers are never routed to a “black hole” region that is technically “up” but practically broken.
-
No Manual Intervention: The propagation of health states is handled by Google’s software-defined networking, requiring no manual updates to routing tables during an incident.
How to configure it?
To configure Private Service Connect health, the service producer must create three primary resources that define how health is measured and where that status is sent. The following gcloud commands demonstrate how a service producer sets up a health aggregation policy, links it to their backend service, and connects it to the consumer-facing forwarding rule.
# 1. Create a health aggregation policy
# This defines that the service is "Healthy" only if 60% of backends are up.
gcloud beta compute health-aggregation-policies create my-psc-policy \
--region=us-central1 \
--healthy-percent-threshold=60 \
--min-healthy-threshold=1
# 2. Create a health source
# This links the policy to your actual producer backend service.
gcloud beta compute health-sources create my-psc-health-source \
--region=us-central1 \
--source-type=BACKEND_SERVICE \
--sources=my-producer-backend-service \
--health-aggregation-policy=my-psc-policy
# 3. Create a composite health check
# This sends the aggregated health signal to the producer's forwarding rule.
gcloud beta compute composite-health-checks create my-composite-hc \
--region=us-central1 \
--health-sources=my-psc-health-source \
--health-destination=projects/MY_PROJECT/regions/us-central1/forwardingRules/my-producer-fr
Configuration Logic
-
Aggregation Policy: Acts as the “rulebook” (e.g., “don’t fail over unless more than 40% of my nodes are down”).
-
Health Source: Identifies the specific Internal Load Balancer (ILB) backend that the policy should monitor.
-
Composite Health Check: The “messenger” that takes the result of the policy and pushes it to the Service Attachment so the consumer’s load balancer can see it.
Please consult documentation for more details.
Get Started with Hands-on Learning
Ready to see it in action? Google Cloud has provided a dedicated lab to help you implement and test these health signals in a live environment.