Kubernetes

●HIGH●Orchestration●INTERMEDIATE

Kubernetes Pod CrashLoopBackOff

A pod repeatedly starts, crashes, and restarts with an increasing backoff delay.

Est. Time

25 minutes

Version

v1.0.0

Updated

7/30/2026

Author

AutoDeploy Team

Setup Guide

Download guide

Kubernetes Pod CrashLoopBackOff

Problem

A pod repeatedly starts, crashes, and restarts, cycling through CrashLoopBackOff with an increasing backoff delay between restarts.

Symptoms

`kubectl get pods` shows STATUS CrashLoopBackOff
RESTARTS count keeps climbing
Pod briefly enters Running then exits

Root Cause

The container's main process exits faster than Kubernetes' restart backoff can keep up with — usually an application error, missing config/secret, a failed dependency, or the wrong container command.

Solution

1. Check the pod's recent events

kubectl describe pod <pod-name> -n <namespace>

2. Read the crashed container's logs

kubectl logs <pod-name> -n <namespace> --previous

3. Check the exit code and reason

kubectl get pod <pod-name> -n <namespace> -o jsonpath='{.status.containerStatuses[0].lastState.terminated}'

4. Verify required ConfigMaps/Secrets exist and are mounted correctly

kubectl get configmap,secret -n <namespace>

5. Check resource limits aren't too low (exit code 137 = OOM, same root cause as Docker)

kubectl top pod <pod-name> -n <namespace>

6. Override the command to keep the container alive for shell debugging

kubectl run debug --image=<image> -it --command -- /bin/sh

Prevention

Add readiness/liveness probes so Kubernetes doesn't route traffic to a pod before it's ready
Fail fast with clear stderr logging so `--previous` logs are actually useful
Set resource requests/limits based on real profiling, not guesses
Validate config/secrets exist via an init container before the main process runs

References

Last updated on 7/30/2026 · Part of the AutoDeploy DevOps Documentation library