CrashLoopBackOff is a Kubernetes container state reason. It means a container has terminated repeatedly and Kubernetes is waiting before trying to restart it. The container is in the Waiting state while the delay runs; the status message reports the remaining back-off time. The name can be misleading because a container that exits with code zero can also receive this status when the pod restart policy is Always. section 6.2.1
Understand the restart cycle through these operational rules:
- Apply the restartPolicy at pod level; it governs all containers in the pod. Always restarts containers regardless of exit code, OnFailure restarts only non-zero exits, and Never disables restarts. section 6.2.1
- Expect exponential back-off after repeated termination: Kubernetes restarts immediately first, then waits 10, 20, 40, 80, and 160 seconds, reaching a five-minute maximum. section 6.2.1
- Reset the delay after the container runs successfully for 10 minutes; a later restart then begins immediately. section 6.2.1
- Treat failing post-start hooks as another trigger: a hook that cannot execute or returns a non-zero exit code causes the entire container to restart. section 6.3.1
Watching a repeatedly terminated container
After repeatedly calling Envoy’s /quitquitquit endpoint, watch the pod with kubectl get pods -w. The pod alternates between Running and NotReady, its restart count increases, and its container status eventually reports Waiting with reason CrashLoopBackOff. Inspect pod events as well, because a rapidly changing status may hide the original failure or hook error. section 6.2.1 section 6.3.1
$ kubectl get po kiada-ssl -o json | jq .status.containerStatuses
...
"state": {
"waiting": {
"message": "back-off 40s restarting failed container=envoy ...",
"reason": "CrashLoopBackOff"Inspect containerStatuses to see the Waiting state, the CrashLoopBackOff reason, and a message such as “back-off 40s restarting failed container.” section 6.2.1
