If you are seeing CrashLoopBackOff in your Kubernetes cluster, here is how to fix it.
What This Error Means
CrashLoopBackOff means your container keeps crashing and Kubernetes keeps restarting it, with increasing backoff delays. The container starts, fails, restarts, fails again — each time waiting longer before the next attempt.
Common causes:
- Application error or misconfiguration
- Missing environment variables or config files
- Wrong command or entrypoint
- Insufficient resources
- Failed dependency (database not reachable)
How to Diagnose
# Check pod status
kubectl get pods -o wide
# Describe the affected pod
kubectl describe pod <pod-name>
# Check events
kubectl get events --sort-by='.lastTimestamp' -ACheck Container Logs
# Current logs
kubectl logs <pod-name>
# Previous crashed container logs
kubectl logs <pod-name> --previous
# If multi-container pod
kubectl logs <pod-name> -c <container-name> --previousCommon Fixes
1. Missing Environment Variables
# Check what env vars the pod expects
kubectl describe pod <pod-name> | grep -A5 'Environment'
# Fix by updating the deployment
kubectl set env deployment/<name> DATABASE_URL=postgres://db:5432/mydb2. Wrong Command
# Check the container command
spec:
containers:
- name: app
image: myapp:latest
command: ["/bin/sh", "-c", "./start.sh"] # Is this correct?3. Resource Limits Too Low
resources:
requests:
memory: 256Mi # Increase if OOM
cpu: 100m
limits:
memory: 512Mi
cpu: 500m4. Debug with Ephemeral Container
kubectl debug <pod-name> -it --image=busybox --target=<container-name>Verify the Fix
# Watch pod status
kubectl get pods -w
# Should show Running with 0 restarts
kubectl get pods | grep <pod-name>Prevention
- Set proper resource requests and limits
- Use pod disruption budgets for critical workloads
- Monitor cluster health with Prometheus and Grafana
- Implement proper health checks (readiness and liveness probes)
