CrashLoopBackOff: replicas that keep crashing after they start
A crash loop is a replica that starts, dies within seconds, waits, and tries again — with a longer wait each time. Kubernetes reports it as CrashLoopBackOff.
What causes it
Under heavy load the loop often looks like this: one replica runs out of memory, its share of the work lands on the survivors, they run out of memory too, and each restarted replica is immediately handed the whole backlog. The back-off (10 s, 20 s, 40 s …) means capacity comes back far slower than it left.
How to recognise it
- Restart count climbing on pods or instances
- Replicas alternate between running and restarting
- Capacity never recovers even though autoscaling adds replicas
Error messages you will see
| Error | Seen in |
|---|---|
CrashLoopBackOff | Kubernetes, Amazon EKS, Amazon ECS, AWS Fargate, Google Kubernetes Engine, Azure Kubernetes Service and 1 more |
How to fix it
- Give replicas more memory
- Limit queued work per replica
- Scale out before load arrives
Reproduce it in the simulator
Open the simulator, build a small architecture and use Fault injection in the inspector, or push traffic past a component’s capacity.
Learn more
Part of the guide Load balancing and capacity planning.