Readiness probe failed: The pod was removed from its Service's endpoints but was not restarted

A failing readiness probe stops traffic reaching the pod. Nothing is killed. This is the probe that should check dependencies, and a pod stuck at 0/1 Ready is usually failing one.

Applies to: All Kubernetes versions

What it means

A readiness probe answers a different question from a liveness probe: should this pod receive traffic right now? On failure the pod's Ready condition goes false and the endpoints controller removes its address from the Service, so the load balancer stops sending it requests. The container keeps running. That makes readiness the correct place to express temporary unavailability — a cache still warming, a dependency briefly unreachable, a queue backing up — because the pod can recover and rejoin without a restart. A pod showing 0/1 in the READY column while its status is Running is the visible signature of this.

Most common causes

• The application has not finished initialising and correctly reports itself not ready.
• A dependency the readiness endpoint checks is down or slow.
• The probe's path, port, or scheme does not match what the container serves — for example probing HTTP against a TLS-only port.
• timeoutSeconds too low for an endpoint that queries dependencies.
• The application listens only on 127.0.0.1, so the kubelet, which probes the pod IP, cannot reach it.
• A network policy blocking the kubelet's probe traffic to the pod.

How to diagnose it

1. Confirm the pod's readiness: kubectl get pod POD and look at the READY column, then kubectl describe pod POD for the probe failure message.
2. Check whether the Service has any endpoints at all: kubectl get endpointslices -l kubernetes.io/service-name=SERVICE. No endpoints and a 503 from the Service is the downstream symptom of this.
3. Check the listening address inside the container: an application bound to localhost is invisible to the kubelet.
4. Call the readiness endpoint from another pod in the namespace to see what it actually returns.
5. Verify the scheme — httpGet defaults to HTTP, and probing an HTTPS-only port with it fails at the TLS handshake.

How to fix it

1. Bind the application to 0.0.0.0 rather than 127.0.0.1 so the probe can reach it.
2. Correct the path, port, and scheme to match the served endpoint.
3. Raise timeoutSeconds and failureThreshold if the endpoint legitimately takes time under load.
4. Keep the readiness endpoint honest — it should report not-ready when the pod genuinely cannot serve, and ready otherwise. An endpoint that always returns 200 makes the probe decorative.
5. Allow kubelet probe traffic explicitly if a network policy is blocking it.

Notes

During a rolling update, readiness is what makes the rollout safe: a new pod receives no traffic until it passes. A readiness probe that returns 200 unconditionally removes that protection while appearing to provide it, which is worse than having no probe at all.

Related

• Liveness probe failed — The container was restarted as unhealthy
• Service has no endpoints — No ready pods behind the Service

Sources

• Kubernetes documentation — Configure Liveness, Readiness and Startup Probes
• Kubernetes documentation — Pod Lifecycle: container probes
• Kubernetes documentation — Service