How to debug Kubernetes pods stuck in CrashLoopBackOff status?

Question

0

After deploying a new microservice container to Kubernetes, the pod enters a state of CrashLoopBackOff. The container starts, crashes almost immediately, and restarts in an exponential backoff loop. What systematic troubleshooting commands should be used to diagnose why the container keeps failing?

Troubleshooting Steps

Run these standard kubectl commands to retrieve logs and event records:

kubectl logs: Fetch recent stdout/stderr output from the failing container
kubectl describe pod: Inspect recent cluster events and exit codes
kubectl get events: View cluster-wide lifecycle events

Reading Exit Codes

Check the container status details to inspect exit codes:

Exit Code 1 or 127: Application error or missing executable script
Exit Code 137: Container was terminated by OOMKilled (Out of Memory)
Exit Code 139: Segmentation fault within the application code

1 Answer

Write Your Answer

Answer 1

CrashLoopBackOff means Kubernetes keeps restarting a container that exits, then waits longer between restart attempts. It describes the restart behavior, not the underlying cause. Start by checking what the container reported just before it stopped.

# Check the pod's current state and restart count.
kubectl get pod <pod-name> -n <namespace>

# Read logs from the previous container instance; this is often the most useful clue.
kubectl logs <pod-name> -n <namespace> --previous

# Inspect container state, exit code, probes, and recent events.
kubectl describe pod <pod-name> -n <namespace>

# If the pod has multiple containers, specify the container name.
kubectl logs <pod-name> -n <namespace> -c <container-name> --previous

Look at the container's last termination reason and the events at the bottom of the describe output. OOMKilled usually points to memory pressure or a limit that's too low. Exit code 1 often means the application failed during startup; check its previous container logs for a configuration error, missing dependency, or invalid command. A liveness probe that fails before the application is ready can also trigger repeated restarts, so review the liveness probe settings and startup time.

If the pod cannot start far enough to produce application logs, check events for scheduling, volume mount, or image pull errors. If it restarts too quickly to inspect, temporarily increase startup tolerance or run a diagnostic version of the container with the same configuration. Make a small change, redeploy, and check whether the restart count stops climbing.

Useful clues are usually in the previous container logs, the pod's last termination state, and recent pod events—not in the CrashLoopBackOff label itself.