How to fix CrashLoopBackOff in Kubernetes

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

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.

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

kubectl logs <pod-name> --previous

For multi-container pods, specify the container:

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

These logs often reveal the exact error causing the crash.

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

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

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

resources:
  limits:
    memory: "512Mi"
  requests:
    memory: "256Mi"

Aggressive liveness probes can kill containers before they finish starting:

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.

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

command: ["sleep", "infinity"]

Then exec into the container to investigate:

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

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

Check that all required configuration is present:

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

Verify secrets and configmaps exist:

kubectl get secrets
kubectl get configmaps

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