Ingress 503: The ingress had no healthy backend to send the request to

A 503 from an ingress almost always means the Service behind the rule has no endpoints — no pods match its selector, or none of them are Ready.

Applies to: All Kubernetes versions with an ingress controller

What it means

When an ingress controller has a routing rule but no usable backend for it, it returns 503. The chain from ingress to running pod has several links and any one of them breaks it: the Ingress names a Service, the Service selects pods by label, and the endpoints controller lists only the ready ones. A 503 therefore points at an empty endpoint list far more often than at anything wrong with the ingress itself. The other significant cause is a mismatch in the Ingress definition — a service name that does not exist in that namespace, or a port number that the Service does not expose — which produces the same response for a different reason.

Most common causes

• The Service has no endpoints because no pod matches its selector or none are Ready.
• The Ingress references a Service name that does not exist in its namespace.
• The Ingress references a Service port that the Service does not define.
• All backend pods are failing readiness probes, for example during a bad rollout.
• The Ingress and the Service are in different namespaces — an Ingress can only reference Services in its own.
• The ingress controller's own configuration has not reloaded after a change.

How to diagnose it

1. Check endpoints first: kubectl get endpointslices -l kubernetes.io/service-name=SERVICE -n NAMESPACE. Empty is the answer most of the time.
2. Read the Ingress and confirm the service name and port exist: kubectl describe ingress INGRESS -n NAMESPACE.
3. Check pod readiness: kubectl get pods -n NAMESPACE and look at the READY column.
4. Confirm the Ingress and Service are in the same namespace.
5. Read the controller's logs for its view of the backend.

How to fix it

1. Fix whatever is keeping pods from being Ready — usually the readiness probe or the application behind it.
2. Correct the service name and port in the Ingress so they match the Service definition.
3. Move the Ingress into the Service's namespace, or create a Service in the Ingress's namespace pointing at the right place.
4. Correct the Service's selector if it matches no pods.
5. Restart the ingress controller only if its configuration is genuinely stale — this is rarely the real cause.

Notes

During a rolling update with a failing new image, every new pod fails readiness while the old ones are terminated, and the ingress returns 503 for the whole window. Setting maxUnavailable: 0 keeps old pods serving until new ones are actually ready, which prevents this specific outage.

Related

• Service has no endpoints — No ready pods behind the Service
• Ingress 502 — The backend returned an invalid response

Sources

• Kubernetes documentation — Ingress
• Kubernetes documentation — EndpointSlices
• Kubernetes documentation — Debug Services