How to fix Liveness probe failed: HTTP probe failed with statuscode: 503 in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 6, 2025· 170 views

A container fails health checks repeatedly, triggering kubelet to restart it continuously. This causes CrashLoopBackOff state. Fix by increasing initialDelaySeconds to allow startup, using startup probes for slow-starting apps, or tuning timeouts and thresholds.

Quick fix

Fixes Liveness probe failed: HTTP probe failed with statuscode: 503

kubectl get pod <pod-name> -n <namespace>
kubectl describe pod <pod-name> -n <namespace>
  1. Check pod restarts and probe failures
  2. Review current probe configuration
  3. Increase initialDelaySeconds
  4. For slow-starting apps, add startup probe
kubernetes — error
kubectl get pod <pod-name> -n <namespace>
kubectl describe pod <pod-name> -n <namespace>
Liveness probe failed: HTTP probe failed with statuscode: 503

What this error means

A liveness probe is a health check that runs periodically (default every 10 seconds) while a container is running. If the probe fails enough times (default 3 failures), kubelet restarts the container. Liveness probes detect deadlocks, hangs, or applications that are running but unresponsive. The error means the probe couldn't communicate with the application or the application returned a failure status. This differs from readiness probes, which remove pods from service load balancing without restarting.

Typical symptoms

  • Container continuously restarting (CrashLoopBackOff state)
  • Pod shows "Back-off restarting failed container"
  • High restart count in pod status
  • Manual test (e.g., curl) succeeds but kubelet probe fails
  • Intermittent failures under high load
  • Application startup takes longer than initialDelaySeconds
  • Probe timeout too short for slow endpoints

Common causes

  1. initialDelaySeconds too low; application still starting when probe runs
  2. Application deadlock, hang, or resource exhaustion under load
  3. timeoutSeconds too short for slow application response
  4. Probe configured for wrong port, path, or protocol
  5. Insufficient CPU/memory causing timeouts
  6. Database or external dependency unavailable
  7. Application logic throwing exceptions during probe checks

How to fix "Liveness probe failed: HTTP probe failed with statuscode: 503"

1Check pod restarts and probe failures

View pod status:

bash
kubectl get pod <pod-name> -n <namespace>
kubectl describe pod <pod-name> -n <namespace>

Look for restart count and "Last State: Terminated" with reason "Unhealthy".

2Review current probe configuration

Check the pod spec:

bash
kubectl get pod <pod-name> -n <namespace> -o yaml | grep -A15 livenessProbe

Note initialDelaySeconds, timeoutSeconds, periodSeconds, and failureThreshold.

3Increase initialDelaySeconds

Default (0) may be too low. Allow more time for startup:

yaml
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 90  # Increased from default
  periodSeconds: 10
  failureThreshold: 3

For Java apps or apps with migrations, use 120-180 seconds.

4For slow-starting apps, add startup probe

Startup probe gives initial window, blocks liveness:

yaml
startupProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 30  # 300 seconds total = 30 * 10s
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 10
  failureThreshold: 3

Startup probe runs until success, then liveness takes over.

5Tune timeouts and thresholds

Increase tolerances for slow endpoints:

yaml
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 60
  timeoutSeconds: 5  # Increased from default 1
  periodSeconds: 15  # Increased from default 10
  failureThreshold: 5  # Increased from default 3
6Verify probe endpoint exists and responds

Exec into container and test:

bash
kubectl exec -it <pod-name> -n <namespace> -- /bin/bash
curl -v http://localhost:8080/health

Or from your local machine if service is exposed:

bash
kubectl port-forward <pod-name> 8080:8080
curl -v http://localhost:8080/health
7Allocate more resources if under load

Resource starvation causes timeout:

yaml
resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

Check pod resource usage:

bash
kubectl top pod <pod-name> -n <namespace>
8Check application logs for errors

Application may be hanging or throwing errors:

bash
kubectl logs <pod-name> -n <namespace> --tail=100
kubectl logs <pod-name> -n <namespace> --previous  # Previous restart

Look for database connection errors, deadlocks, or resource exhaustion messages.

Advanced notes

Liveness probes should only be used for true "is application alive" checks—use readiness probes for "can accept traffic" checks. Avoid expensive operations (full health scans, database queries) in liveness probes; use lightweight endpoints. Best practice: separate /health (readiness) from /liveness endpoints. Use higher failureThreshold for liveness (e.g., 3-5) to tolerate temporary blips. For stateful apps, ensure data consistency before declaring readiness. Monitor probe success rates in cluster metrics; sudden failures indicate application or infrastructure issues. Use TCP socket probes for simple connectivity checks; HTTP probes for application logic. For gRPC apps, use gRPC probe type (Kubernetes 1.24+) instead of HTTP.

Frequently asked questions

What does "Liveness probe failed: HTTP probe failed with statuscode: 503" mean?
A liveness probe is a health check that runs periodically (default every 10 seconds) while a container is running. If the probe fails enough times (default 3 failures), kubelet restarts the container. Liveness probes detect deadlocks, hangs, or applications that are running but unresponsive.
How do I fix "Liveness probe failed: HTTP probe failed with statuscode: 503"?
A container fails health checks repeatedly, triggering kubelet to restart it continuously. This causes CrashLoopBackOff state. Fix by increasing initialDelaySeconds to allow startup, using startup probes for slow-starting apps, or tuning timeouts and thresholds.
What causes "Liveness probe failed: HTTP probe failed with statuscode: 503"?
initialDelaySeconds too low; application still starting when probe runs Application deadlock, hang, or resource exhaustion under load timeoutSeconds too short for slow application response
Is the "Liveness probe failed: HTTP probe failed with statuscode: 503" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading