How to fix CrashLoopBackOff in Kubernetes

KubernetesINTERMEDIATEHIGHUpdated Dec 6, 2025· 257 views

CrashLoopBackOff indicates a container is repeatedly crashing and restarting. Kubernetes applies exponential backoff delays between restarts while you diagnose the underlying application or configuration issue.

Quick fix

Fixes CrashLoopBackOff

kubectl get pods
kubectl describe pod <pod-name>
  1. Check pod status and recent events
  2. View container logs from previous crash
  3. Verify resource limits are adequate
  4. Review liveness probe configuration
kubernetes — error
kubectl get pods
kubectl describe pod <pod-name>
CrashLoopBackOff

What this error means

CrashLoopBackOff is not an error itself but a pod state indicating that a container is stuck in a restart loop. When a container crashes, Kubernetes automatically restarts it according to the pod's restart policy. If the container keeps crashing, Kubernetes implements exponential backoff delays (10s, 20s, 40s, up to 5 minutes) between restart attempts to prevent resource exhaustion. This state appears when something fundamental prevents the container from starting successfully—whether it's a misconfigured application, missing dependencies, resource constraints, or probe failures. The actual root cause requires investigation through logs and pod events.

Typical symptoms

  • Pod status shows CrashLoopBackOff in kubectl get pods output
  • Container restart count keeps incrementing over time
  • Pod events show Back-off restarting failed container messages
  • Application logs show errors or exceptions before termination
  • Last State shows Terminated with non-zero exit code
  • Increasing delays between container restart attempts
  • Liveness probe failures visible in kubectl describe pod output

Common causes

  1. Application crashes due to unhandled exceptions or fatal errors in code
  2. Liveness probe misconfiguration with insufficient initialDelaySeconds
  3. Out of memory (OOMKilled) due to resource limits set too low
  4. Missing or misconfigured environment variables required by the application
  5. Command or entrypoint errors in container specification
  6. Missing dependencies or files not present in the container image
  7. Database or external service connection failures during startup
  8. File permission issues preventing application execution

How to fix "CrashLoopBackOff"

1Check pod status and recent events

Get an overview of the pod state and any cluster events:

bash
kubectl get pods
kubectl describe pod <pod-name>

Look at the Events section for clues about why the container is failing. Check the Last State field for exit codes—137 indicates OOMKilled, 1 typically means application error.

2View container logs from previous crash

Since the container keeps crashing, you need to see logs from the previous instance:

bash
kubectl logs <pod-name> --previous

For multi-container pods, specify the container:

bash
kubectl logs <pod-name> -c <container-name> --previous

These logs often reveal the exact error causing the crash.

3Verify resource limits are adequate

Check if the container is being OOMKilled due to memory limits:

bash
kubectl describe pod <pod-name> | grep -A 5 'Last State'

If you see "OOMKilled" or exit code 137, increase memory limits in your deployment:

yaml
resources:
  limits:
    memory: "512Mi"
  requests:
    memory: "256Mi"
4Review liveness probe configuration

Aggressive liveness probes can kill containers before they finish starting:

yaml
livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 60  # Give app time to start
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3

Increase initialDelaySeconds if your application needs more startup time.

5Debug interactively by overriding the entrypoint

If logs don't reveal the issue, start a debugging session by overriding the container command:

yaml
command: ["sleep", "infinity"]

Then exec into the container to investigate:

bash
kubectl exec -it <pod-name> -- /bin/sh

Manually run the application command to see real-time errors.

6Verify environment variables and secrets

Check that all required configuration is present:

bash
kubectl get pod <pod-name> -o jsonpath='{.spec.containers[0].env}' | jq

Verify secrets and configmaps exist:

bash
kubectl get secrets
kubectl get configmaps

Missing or empty environment variables are a common cause of startup failures.

Advanced notes

On GKE, use the interactive debugging playbook in Cloud Console for guided troubleshooting. For EKS, check IAM role attachments if your application connects to AWS services. In AKS, verify your container image architecture matches the cluster node architecture (AMD64 vs ARM64).

For Java applications, remember that JVM heap settings don't account for all memory usage—native threads and off-heap memory can push containers over their limits. Set container memory limits higher than JVM max heap.

In CI/CD pipelines, CrashLoopBackOff often indicates missing secrets that exist in production but not in the deployment environment. Use kubectl diff to compare configurations across environments.

Frequently asked questions

What does "CrashLoopBackOff" mean?
CrashLoopBackOff is not an error itself but a pod state indicating that a container is stuck in a restart loop. When a container crashes, Kubernetes automatically restarts it according to the pod's restart policy. If the container keeps crashing, Kubernetes implements exponential backoff delays (10s, 20s, 40s, up to 5 minutes) between restart attempts to prevent resource exhaustion.
How do I fix "CrashLoopBackOff"?
CrashLoopBackOff indicates a container is repeatedly crashing and restarting. Kubernetes applies exponential backoff delays between restarts while you diagnose the underlying application or configuration issue.
What causes "CrashLoopBackOff"?
Application crashes due to unhandled exceptions or fatal errors in code Liveness probe misconfiguration with insufficient initialDelaySeconds Out of memory (OOMKilled) due to resource limits set too low
Is the "CrashLoopBackOff" 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