How to fix Failing Readiness Probe in Kubernetes

KubernetesBEGINNERMEDIUMUpdated Sep 25, 2026· 247 views

A failing readiness probe prevents a pod from receiving traffic. The readiness probe indicates if a container is ready to serve requests. When it fails, the pod is removed from load balancing but the container keeps running, allowing debugging without service disruption.

Quick fix

Fixes Failing Readiness Probe

kubectl describe pod <pod-name> -n <namespace> | grep -A 10 "Readiness"
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 10 "readinessProbe:"
kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
  1. View readiness probe configuration and status
  2. Check pod logs for readiness-related errors
  3. Test the readiness endpoint manually
  4. Check if dependencies are available
kubernetes — error
kubectl describe pod <pod-name> -n <namespace> | grep -A 10 "Readiness"
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 10 "readinessProbe:"
kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
Failing Readiness Probe

What this error means

The readiness probe signals: "Am I ready to handle traffic?" When it fails: - Pod is removed from service endpoints (no traffic sent) - Container continues running (no restart) - Load balancer stops routing requests to the pod Unlike liveness probes (which restart), readiness probes allow graceful degradation. A failing readiness probe is often temporary (warming up, waiting for dependencies) and resolves without intervention.

Typical symptoms

  • Pod shows "Running" but "0/1 Ready" status
  • kubectl get pods shows <ready> as 0/1 instead of 1/1
  • Service endpoints don't include the pod (kubectl get endpoints)
  • Traffic doesn't reach the pod despite it running
  • kubectl describe pod shows "Readiness probe failed"
  • Events show repeated "Readiness probe failed" messages
  • Pod never transitions to Ready state after starting

Common causes

  1. Application startup not complete when readiness check runs
  2. readiness probe checking external dependency (database, API) that's unavailable
  3. Probe endpoint returns HTTP 500 or connection refused
  4. initialDelaySeconds too low—app not ready when first probe runs
  5. Application is overloaded and can't respond to probe in time
  6. Network policy or firewall blocking probe traffic
  7. Wrong port or path configured in the probe

How to fix "Failing Readiness Probe"

1View readiness probe configuration and status

Check the current probe settings:

bash
kubectl describe pod <pod-name> -n <namespace> | grep -A 10 "Readiness"
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A 10 "readinessProbe:"
kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'

Example output:

bash
Readiness: http-get delay=10s timeout=5s period=10s #success=1 #failure=3

Note: delay (initialDelaySeconds), timeout, period, and thresholds.

2Check pod logs for readiness-related errors

View what the application is doing:

bash
kubectl logs <pod-name> -n <namespace> -f
kubectl logs <pod-name> -n <namespace> --tail=100 | grep -i "ready\|waiting\|error"

# Check for repeated failures:
kubectl logs <pod-name> -n <namespace> | head -30  # First log lines
kubectl logs <pod-name> -n <namespace> | tail -30  # Last log lines

Look for:
- "Database not connected"
- "Cache not initialized"
- "Waiting for dependencies"

3Test the readiness endpoint manually

Run the readiness check from inside the pod:

bash
# Execute the probe command directly:
kubectl exec -it <pod-name> -n <namespace> -- sh

# For HTTP probe:
curl -v http://localhost:8080/ready
curl -v http://localhost:8080/readiness
echo $?  # Should return 0 and HTTP 200

# For TCP probe:
nc -zv localhost 8080

# For exec probe:
/bin/ready-check.sh

# Check response time:
time curl http://localhost:8080/ready

If the probe fails or times out, you've found the issue.

4Check if dependencies are available

Verify the application can reach its dependencies:

bash
# From inside the pod:
kubectl exec -it <pod-name> -n <namespace> -- sh

# Check database connectivity:
nc -zv database-host 5432
psql -h database-host -U user -d mydb -c "SELECT 1"

# Check cache/Redis:
redis-cli -h redis-host ping

# Check other services:
curl -v http://api-service:8080/health

# Check DNS:
nslookup database-host
getent hosts database-host

If dependencies are unreachable, the readiness check will fail.

5Increase initialDelaySeconds to allow startup time

Give the application more time to initialize:

bash
# Patch the deployment:
kubectl patch deployment <name> -n <namespace> -p '{"spec":{"template":{"spec":{"containers":[{"name":"<container>","readinessProbe":{"initialDelaySeconds":60}}]}}}}'

# Or edit YAML:
kubectl edit deployment <name> -n <namespace>

Example:

yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ready-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: myapp:latest
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 45  # Wait 45 seconds before first check
          periodSeconds: 10
          failureThreshold: 3

Rule: initialDelaySeconds should be > max startup time.

6Increase readiness probe timeout

Allow more time for the probe to complete:

bash
kubectl patch deployment <name> -n <namespace> -p '{"spec":{"template":{"spec":{"containers":[{"name":"<container>","readinessProbe":{"timeoutSeconds":10}}]}}}}'

# Or edit YAML:
yaml
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 10  # Increase from default 1 to 10
  failureThreshold: 3

Timeout should be reasonable (3-10s) but not excessive.

7Implement a proper readiness endpoint

Create a readiness check that verifies initialization:

python
# Python/Flask example:
@app.route('/ready', methods=['GET'])
def readiness():
    """Readiness check: is the app ready to serve traffic?"""
    try:
        # Check if application has completed initialization
        if not app.config.get('initialized'):
            return jsonify({'status': 'not_ready'}), 503
        
        # Check database connectivity
        db.session.execute('SELECT 1')
        
        # Check cache (optional)
        if app.config.get('use_cache'):
            cache.ping()
        
        return jsonify({'status': 'ready'}), 200
    except Exception as e:
        print(f"Readiness check failed: {e}")
        return jsonify({'status': 'error', 'message': str(e)}), 503

Return 200 only when truly ready. Use 503 for not ready (load balancer will remove from endpoints).

8Don't check external services in readiness probes

Readiness probes should check only if the pod is ready, not if external services are available:

Bad (checks external service):

yaml
readinessProbe:
  httpGet:
    path: /api/external-service/status
    port: 8080

If external service is down, your pod becomes NotReady, cascading failure.

Good (checks local readiness):

yaml
readinessProbe:
  httpGet:
    path: /ready  # Just check if app is initialized
    port: 8080

If external service is needed, handle it gracefully in the application (retry, cache, fallback).

Advanced notes

Unlike liveness probes, readiness failures don't restart containers—they just remove the pod from load balancing. This is useful for: slow startups, temporary unavailability of dependencies, or rolling updates. Use liveness for "is the container alive" and readiness for "is it ready to serve". A pod can be Running but not Ready. Always implement proper health check endpoints rather than relying on default probes. In cloud environments (AKS, EKS), ensure network policies allow readiness checks from the kubelet. Startup probes (K8s 1.18+) are better than high initialDelaySeconds for slow-starting apps. For databases, use readiness checks to detect unavailability but continue running—don't cascade failures. Implement exponential backoff in application startup to avoid probe failures during load.

Frequently asked questions

What does "Failing Readiness Probe" mean?
" When it fails: - Pod is removed from service endpoints (no traffic sent) - Container continues running (no restart) - Load balancer stops routing requests to the pod Unlike liveness probes (which restart), readiness probes allow graceful degradation. A failing readiness probe is often temporary (warming up, waiting for dependencies) and resolves without intervention.
How do I fix "Failing Readiness Probe"?
A failing readiness probe prevents a pod from receiving traffic. The readiness probe indicates if a container is ready to serve requests. When it fails, the pod is removed from load balancing but the container keeps running, allowing debugging without service disruption.
What causes "Failing Readiness Probe"?
Application startup not complete when readiness check runs readiness probe checking external dependency (database, API) that's unavailable Probe endpoint returns HTTP 500 or connection refused
Is the "Failing Readiness Probe" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading