How to Fix CrashLoopBackOff in Kubernetes

Your pod keeps restarting and `kubectl get pods` shows the status `CrashLoopBackOff`. The container starts, exits with a non-zero code, and Kubernetes backs off before restarting it — over and over.

$ kubectl get pods
NAME                     READY   STATUS             RESTARTS   AGE
api-7f5d4b6f4c-x2qzr     0/1     CrashLoopBackOff   12         34m

CrashLoopBackOff is a symptom, not a cause. The container is exiting and Kubernetes is rate-limiting the restarts. Common underlying causes:

• Application crash on startup (missing env var, bad config, failing migration).
• Liveness probe failing before the app is ready.
• Out-of-memory kill (OOMKilled) due to a too-low memory limit.
• Wrong command/entrypoint or missing binary in the image.
• Missing ConfigMap, Secret, or volume mount path.

1. Read the previous container's logs

kubectl logs <pod> --previous

The `--previous` flag gives you the logs from the last crashed instance — the current one usually has nothing yet.

2. Describe the pod for events and exit code

kubectl describe pod <pod>

Look at the `Last State` block. Exit code 137 means OOMKilled, 1 is a generic app error, 143 is a SIGTERM that didn't complete in time.

3. Fix the underlying issue

• Exit code 137 → raise `resources.limits.memory` or fix the memory leak.
• Missing env var → check your Deployment manifest and referenced Secret/ConfigMap exists.
• Probe failing too early → add `initialDelaySeconds` or use a `startupProbe`.
• ImagePullBackOff hiding behind it → confirm image tag and pull secret.

4. Roll the deployment after fixing

kubectl rollout restart deployment/<name>