Fix Kubernetes CrashLoopBackOff: Container Keeps Restarting

Fix Kubernetes CrashLoopBackOff: Container Keeps Restarting

You run kubectl get pods and see this:

NAME          READY   STATUS             RESTARTS   AGE
api-7d9f8b    0/1     CrashLoopBackOff   8          12m

CrashLoopBackOff means the container is starting, crashing, and Kubernetes is restarting it — with an increasing delay between attempts (10s → 20s → 40s → 80s → 160s → 5 minutes). The back-off prevents a broken container from hammering the node.

The status tells you that the container is crashing. It doesn't tell you why. That's what you need to find.

Step 1: Get the actual error

# Show the crash reason and exit code
kubectl describe pod <pod-name>

Look at the Last State section and the Events section:

Last State:     Terminated
  Reason:       Error
  Exit Code:    1
  Started:      Mon, 01 Jun 2026 10:00:00
  Finished:     Mon, 01 Jun 2026 10:00:02

Then get the logs from the crashed container (not the current attempt — the previous one):

kubectl logs <pod-name>                # Logs from current attempt (may be empty)
kubectl logs --previous <pod-name>    # Logs from last terminated container ← this is the one
kubectl logs --previous <pod-name> --tail=50  # Last 50 lines if output is large

--previous is the most important flag here. It shows what the container printed before it died.

Cause 1: Application error on startup

The most common cause. The app throws an exception, fails to connect to something, or finds a missing config and exits with a non-zero code.

What you'll see: logs showing an error, stack trace, or Error: ENOTFOUND, connection refused, cannot read property of undefined, etc.

Fix: Read the logs. This is an application bug, not a Kubernetes bug. Common sub-causes:

• Missing environment variable → add it to env: or envFrom: in the pod spec
• Can't connect to the database → the database service isn't ready; use an init container to wait
• Wrong configuration file path → fix the path or mount the ConfigMap correctly

Cause 2: OOMKilled — out of memory

If kubectl describe pod shows Reason: OOMKilled in Last State, the container hit its memory limit and was killed by the kernel.

Last State:  Terminated
  Reason:    OOMKilled
  Exit Code: 137

Exit code 137 = SIGKILL from the kernel (128 + 9).

Fix: Raise the memory limit, or fix the memory leak.

resources:
  limits:
    memory: "512Mi"   # Raise this
  requests:
    memory: "256Mi"

Cause 3: Wrong command or entrypoint

If the container exits immediately with exit code 0 or 127:

• Exit code 0: the command ran successfully and exited — correct for batch jobs, wrong for a server
• Exit code 127: command not found — the binary path is wrong

kubectl describe pod <pod-name>
# Look at: Command, Args in the container spec

Fix: Correct the command/args in the pod spec, or check the image's CMD/ENTRYPOINT.

Cause 4: Liveness probe killing the container

A misconfigured liveness probe can restart a healthy container. If the probe path is wrong, the port doesn't match, or initialDelaySeconds is too short for a slow-starting app, Kubernetes will kill and restart the container thinking it's unhealthy.

What you'll see: kubectl describe pod → Events → Liveness probe failed: ...

Fix: Increase initialDelaySeconds or use a startupProbe to gate the liveness probe until the app is fully started:

1startupProbe:
2  httpGet:
3    path: /health
4    port: 3000
5  failureThreshold: 30      # Allow up to 5 minutes to start
6  periodSeconds: 10
7
8livenessProbe:
9  httpGet:
10    path: /health
11    port: 3000
12  initialDelaySeconds: 0    # startupProbe handles the delay
13  periodSeconds: 20

Cause 5: Missing ConfigMap or Secret

If a ConfigMap or Secret referenced in envFrom: or as a volume doesn't exist, the container won't start at all.

What you'll see in Events:

Error: secret "app-secrets" not found

Fix:

# Check if the referenced ConfigMap/Secret exists
kubectl get configmap app-config -n <namespace>
kubectl get secret app-secrets -n <namespace>

Create it if it's missing, or fix the name in the pod spec.

Quick reference

# The two most important commands for CrashLoopBackOff
kubectl describe pod <name>      # Exit code, reason, events
kubectl logs --previous <name>   # What the app printed before dying

See also

• Debugging CrashLoopBackOff from Scratch
• Fix: Kubernetes OOMKilled — detailed guide for memory limit issues
• Fix: Kubernetes Pending Pods — pod stuck before even starting
• Kubernetes Probes — Liveness, Readiness, Startup — configuring probes correctly
• Build an AI Kubernetes Troubleshooting Agent — automating this triage loop

Frequently Asked Questions

Why is kubectl logs empty for a crashing pod?

It shows the current container, which may have only just started. Add --previous to read the last terminated instance, which is where the failure actually is. This is the most commonly forgotten flag when debugging a crash loop.

What does exit code 137 mean?

The container was killed with SIGKILL, which in Kubernetes almost always means it exceeded its memory limit. Confirm in the pod description, where the last state shows OOMKilled. Raising the limit is the quick fix; check for a leak before treating it as the answer.

The pod restarts before I can inspect it. What now?

The back-off delay grows with each restart, so waiting gives a longer window. For a faster loop, scale the deployment to zero and run a single pod with the command overridden to a shell, which stops Kubernetes restarting it while you look. Events in the pod description persist after the container is gone.

How do I tell a config problem from an application bug?

Read whether the process started at all. A missing environment variable or unmounted ConfigMap usually fails before the application logs anything, and the error comes from the runtime. An application that logs its own startup then dies is a bug or an unreachable dependency, which is a different search.

Official References

• Debug Pods — reading pod status, events and container states
• kubectl reference — command syntax, output formats and selectors