Error: container is in CrashLoopBackOff

The “CrashLoopBackOff” error means your container repeatedly starts, crashes, and restarts with increasing delays — and never reaches a stable Running state.

What It Means

Kubernetes detected that your container exits with a non-zero exit code soon after starting. Each restart increases the backoff delay exponentially (10s, 20s, 40s, 80s, up to 5 minutes). The pod will never reach a Running state until the underlying application crash is fixed.

Why It Happens

• The application has a bug that causes it to crash immediately on startup.
• Required environment variables are missing or incorrect.
• Resource limits are too low (OOMKilled — process killed by out-of-memory).
• The liveness or readiness probe is misconfigured and the container is killed.
• The startup command or arguments are wrong.
• A required file or dependency is missing from the container image.
• The application binds to the wrong port or address.

How to Fix It

Step 1: Check the container logs

kubectl logs <pod-name>
kubectl logs --previous <pod-name>  # Logs from the previous crash

The --previous flag is critical because the current container may have no logs if it crashes before writing anything.

Step 2: Describe the pod for details

kubectl describe pod <pod-name>

Look for:

• State: CrashLoopBackOff with exit code
• Last State: exit code and reason
• Events: OOMKilled, probe failures, image pull errors
• Exit code 137 = OOM killed, exit code 1 = application error

Step 3: Check resource limits

If the pod is being OOMKilled (exit 137):

kubectl describe pod <pod-name> | grep -A2 Limits

Increase memory limits in your deployment:

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

Step 4: Fix the liveness probe

A misconfigured probe can cause Kubernetes to kill a healthy container. Check the probe configuration:

livenessProbe:
  httpGet:
    path: /health
    port: 8080
  initialDelaySeconds: 30  # Give the app time to start
  periodSeconds: 10

If the probe path or port is wrong, the container will be killed repeatedly.

Step 5: Test the container locally

Pull and run the image locally to reproduce the crash:

docker run --rm <image-name>

This isolates whether the issue is in the container image or the Kubernetes configuration.