Error 503 Backend Unhealthy, No Healthy Upstream, all backends failed Fixed.

Your site is down. The error page says, “Error 503 Backend Unhealthy] something about a backend, or an upstream, or all backends failing.

Here’s the fast answer. Every one of these messages means the same core thing. A proxy or load balancer checked its backend targets, found none of them healthy, and refused to route your request.

The exact wording tells you which technology you’re actually dealing with. That matters, because the fix is different for each one.

Error 503 Backend Unhealthy: Step One: Identify Your Technology

Don’t skip this. The right fix depends entirely on which system produced the error.

Exact Wording	Technology
“Backend is unhealthy” or “All backends failed or unhealthy,” with a Guru Meditation XID signature	Varnish Cache
“No Healthy Upstream”	Envoy Proxy, Istio, Ambassador, or AWS App Mesh
“No live upstreams”	nginx
“No server is available”	HAProxy
Generic 503 with target health check failures shown in a cloud console	AWS ALB or GCP Cloud Load Balancer
Repeated 503s tied to instance or Machine health checks on a PaaS platform	Fly.io

Find your exact wording above before doing anything else.

Check This First, Regardless of Platform

A few root causes apply no matter which technology threw the error.

The backend application might simply not be running or might have crashed. Check that first.

The backend might be reachable but returning something unexpected on the specific health check path being probed. A health check hitting the wrong path can fail even when the app itself works fine.

Network-level blocks matter too. Security groups, network ACLs, firewall rules, or Kubernetes NetworkPolicies can quietly prevent the proxy from reaching a perfectly healthy backend.

DNS resolution failures or stale DNS results can point the proxy at an outdated or unreachable address.

Resource pressure, CPU or memory, can cause a backend to respond too slowly to health checks, tripping the timeout even though the app hasn’t crashed.

Rolling deployments can create a short window with no ready instances at all, especially if readiness probes are slow or too few replicas are running.

The Root Cause Most Guides Skip

Here’s one worth checking closely. Database connection pool exhaustion.

In a lot of real incidents, the application process keeps running just fine. But its health check endpoint starts failing or timing out because the app can’t get a database connection. The pool is fully exhausted.

The proxy sees that failed health check and marks the backend unhealthy, even though nothing is actually wrong with the application process itself. Restarting the app won’t fix this if the database connection pressure is still there.

Check your database connection pool metrics and active connection counts alongside your application and proxy logs. Don’t stop at “is the process running.”

Varnish: Backend is Unhealthy / All Backends Failed

If you saw a Guru Meditation XID signature, you’re on Varnish Cache.

Run this command to check backend status directly.

varnishadm backend.list

Each backend will show as either Healthy or Sick. Varnish will not send traffic to anything marked Sick.

If a backend shows Sick, check whether the actual application behind it is running and reachable. Then confirm it’s responding correctly to whatever health check probe Varnish is configured to send.

Envoy and Istio: No Healthy Upstream

This wording points to Envoy Proxy or an Envoy-based system, including Istio, Ambassador, or AWS App Mesh.

The core cause is that every endpoint in a cluster has been evicted from the pool. This happens through active health check failures or through outlier detection, which passively ejects hosts based on observed error rates.

Istio’s DestinationRule controls how aggressively outlier detection ejects unhealthy hosts. If it’s tuned too aggressively, it can eject genuinely healthy hosts during a brief, transient issue, which makes the outage worse instead of better.

Check whether pods or endpoints are actually ready, not just running. A container can be running while still failing readiness checks during startup or after a crash loop.

Also Read: Fixing Crunchyroll Error 503

GCP Cloud Load Balancer: All Backends Unhealthy

This is a common, often-missed cause on Google Cloud specifically.

Health check probes on GCP originate from two specific IP ranges: 130.211.0.0/22 and 35.191.0.0/16. If a firewall rule blocks those ranges while still allowing normal user traffic through, your backends can look completely healthy to real visitors while failing every single health check.

Also check that the health check path, port, and protocol configured on the load balancer actually match what your backend serves. A health check pointed at the wrong path, one that returns a 404, will cause this exact symptom even though your service works fine.

One more thing to rule out. Backends can be at capacity, not actually unhealthy. Too many concurrent connections or requests per second against your configured limits produces a different problem needing a different fix: scaling out or raising limits, not health check debugging.

Fly.io: 503 All Backend Failed

Fly’s proxy stops routing to any Machine that fails its configured health checks. If every Machine for your app fails, users get 503s across the board.

Out-of-memory kills are a common cause here. A Machine that crashes from running out of memory fails its health checks by definition. Check for OOM kill events first, and add memory if you find any.

Slow-starting applications, commonly Rails, Django, or large JVM-based apps, sometimes need a longer health check grace period. Somewhere between 15 and 30 seconds is often enough to stop them from being marked unhealthy before they’ve even finished starting.

A few commands help here directly.

Command	What It Does
fly logs	View live application logs
fly ssh console	Access a Machine directly
fly doctor	Check for networking and configuration issues
fly config validate	Catch syntax errors in fly.toml

nginx and HAProxy: A Quick Note

nginx shows “no live upstreams” when every server in an upstream block is marked down. HAProxy shows “no server is available” for the same underlying reason.

Both follow the same general approach as everything above: confirm the backend application is actually running and reachable, check that health check paths match what the app actually serves, and rule out network-level blocks between the proxy and the backend.

Frequently Asked Questions

What do these error messages actually have in common?

All of them mean a proxy or load balancer found zero backend targets currently passing health checks, so it refused to route the request and returned a 503 instead.

How do I know which technology is producing my specific error?

Match your exact error wording against the identification table above. A Guru Meditation signature means Varnish, “No Healthy Upstream” means Envoy or Istio, and so on.

Why would my backend fail health checks even though the app is running?

Common reasons include a health check hitting the wrong path, resource pressure slowing responses past the timeout, or database connection pool exhaustion causing the health check endpoint itself to fail.

What’s the Varnish-specific way to check backend health?

Run varnishadm backend.list. It shows each backend as Healthy or Sick.

Why do I keep getting this error on GCP Cloud Load Balancer specifically?

A common cause is a firewall rule blocking Google’s health check IP ranges, 130.211.0.0/22 and 35.191.0.0/16, while still allowing normal traffic through.

Why does this happen on Fly.io right after a deploy?

Often an out-of-memory kill, or an app that needs a longer health check grace period to finish starting up before health checks begin.

Can a firewall rule really cause every backend to look unhealthy?

Yes. If health check traffic specifically is blocked while user traffic isn’t, backends can look perfectly fine to visitors while failing every health check.

Is this ever caused by something outside my application code?

Frequently. Database connection pool exhaustion, network policy blocks, DNS resolution failures, and firewall misconfigurations all produce this exact symptom without any bug in your application code.

Quick Reference Summary

Question	Answer
Do all three phrases mean the same core thing	Yes
First step	Identify your exact technology from the wording
Varnish check command	varnishadm backend.list
Common GCP-specific cause	Firewall blocking health check IP ranges
Common Fly.io-specific cause	OOM kills or slow startup
Root cause often missed	Database connection pool exhaustion