A container is running but fails health checks, so Kubernetes removes it from service endpoints. Traffic doesn't route to the pod but the container isn't restarted. Fix by increasing initialDelaySeconds, using startup probes, tuning timeouts, or ensuring the application's health endpoint works correctly.
Fixes Readiness probe failed: HTTP probe failed with statuscode: 503
kubectl get pods -n <namespace> | grep <pod-name>
kubectl describe pod <pod-name> -n <namespace>kubectl get pods -n <namespace> | grep <pod-name>kubectl describe pod <pod-name> -n <namespace>Readiness probe failed: HTTP probe failed with statuscode: 503
A readiness probe checks if a container is ready to accept traffic. Unlike liveness probes that trigger restarts, failed readiness probes simply remove the pod from service endpoints, stopping traffic from reaching it. This is useful for graceful degradation—the container keeps running but doesn't receive requests. The pod stays in Running state but shows NotReady. Readiness probes should check if the application has finished initialization and external dependencies are available.
Verify the pod is running but not ready:
kubectl get pods -n <namespace> | grep <pod-name>
kubectl describe pod <pod-name> -n <namespace>Expect STATUS=Running but READY=0/1 (or similar).
Check the probe spec:
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A15 readinessProbeGive application more time to start:
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 60 # Increased from default
periodSeconds: 10
failureThreshold: 3Startup probe runs once, allowing extended initialization:
startupProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 5
failureThreshold: 30 # ~150 seconds total
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 10
periodSeconds: 10Test the endpoint manually:
kubectl exec -it <pod-name> -n <namespace> -- curl -v http://localhost:8080/readyOr from outside:
kubectl port-forward <pod-name> 8080:8080
curl -v http://localhost:8080/readyApplication may be failing initialization:
kubectl logs <pod-name> -n <namespace> --tail=50Look for database connection errors, dependency failures, or initialization timeouts.
Readiness may fail if databases, caches, or APIs are unavailable:
# Check if database is reachable
kubectl exec <pod-name> -n <namespace> -- \
nc -zv <db-host> <db-port>
# Check DNS resolution
kubectl exec <pod-name> -n <namespace> -- \
nslookup <service-name>Adjust for slow environments:
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 60
timeoutSeconds: 5 # Increased from default 1
periodSeconds: 15 # Increased from default 10
failureThreshold: 5 # Allow more blips before marking not-readyReadiness probes control traffic routing, not container lifecycle. Use /ready endpoint for readiness (checks dependencies) and /health for liveness (checks if still alive). Implement lightweight readiness checks—expensive operations slow down traffic restoration. For stateful apps, ensure state synchronization before declaring readiness. For Deployments without readiness probes, all pods receive traffic immediately; this can cause user-visible errors if startup is slow. Best practice: use both startup and readiness probes for slow-starting apps. Monitor readiness failure rates; persistent failures indicate infrastructure or application issues, not misconfiguration.