CrashLoopBackOff

Pod stuck in CrashLoopBackOff

Product: Kubernetes
Severity: Severity: critical
Updated: Oct 24, 2026
Read: 6 min

The container starts, exits, and is restarted with an exponential back-off. The status is a symptom; the container exit code tells you why.

Error message

Back-off restarting failed container api in pod api-7d9f8c6b5-x2lqz

Symptoms

kubectl get pods shows STATUS CrashLoopBackOff and a rising RESTARTS count.
Readiness never reports true; the Service has no endpoints.
Deployment rollout stalls at "Waiting for rollout to finish".

Cause

Exit code 1: the application threw an unhandled error on startup.
Exit code 137: the container was OOMKilled by the kubelet.
A liveness probe is too aggressive and kills a slow-starting process.
A required ConfigMap, Secret, or environment variable is missing.

Resolution

01
Step 1: Inspect the last termination state
Describe the pod and look for "Last State: Terminated" with its Reason and Exit Code.
bash
```
kubectl describe pod api-7d9f8c6b5-x2lqz -n prod
```
02
Step 2: Read logs from the previous container
The current container may have no output yet. Use --previous to read the crashed instance.
bash
```
kubectl logs api-7d9f8c6b5-x2lqz -n prod --previous
```
03
Step 3: Raise memory limits or relax probes
For exit code 137, increase resources.limits.memory. For probe kills, add a startupProbe so liveness checks wait until the app is up.
yaml
```
startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 5
```

← Back to index