--- tags: - k8s - l1 - flashcard-deck - crashloopbackoff --- [Portal](../../../../library/portal/index.md) | **Level:** [L1: Foundations](../../../../library/portal/levels.md) | **Topics:** [CrashLoopBackOff (alias)](../../../../library/portal/topics.md) | **Domain:** Kubernetes id category difficulty tags question answer source_path crashloopbackoff/a1b2c3d4e5f6 crashloopbackoff easy crashloopbackoff,kubernetes What does CrashLoopBackOff mean? CrashLoopBackOff means a container keeps crashing and Kubernetes is applying exponential backoff before restarting it (10s, 20s, 40s, up to 5 minutes). The container starts, crashes, restarts, crashes again. It is not a root cause — it is a symptom that something is wrong with the container.\n\nRemember: CrashLoopBackOff = container starts, crashes, Kubernetes restarts it with exponential backoff (10s, 20s, 40s, ... up to 5 minutes). It's not an error itself — it's a symptom.\n\nRemember: debugging steps: kubectl logs pod-name (check app logs), kubectl describe pod pod-name (check events), kubectl exec -it pod-name -- sh (if it stays up long enough). training/library/topics/crashloopbackoff/primer.md crashloopbackoff/b2c3d4e5f6a7 crashloopbackoff easy crashloopbackoff,diagnosis What are the first three commands to diagnose CrashLoopBackOff? 1) kubectl describe pod — check Events section for error messages. 2) kubectl logs --previous — see the logs from the crashed container (--previous is crucial since the current container may have no logs yet). 3) kubectl get events --sort-by=.lastTimestamp — broader cluster context.\n\nRemember: the most common CrashLoopBackOff causes are: missing environment variables, wrong image tag, insufficient memory limits, and failed health checks (liveness probe killing the container). training/library/topics/crashloopbackoff/primer.md crashloopbackoff/c3d4e5f6a7b8 crashloopbackoff medium crashloopbackoff,config What are the most common causes of CrashLoopBackOff? 1) Application error (segfault, unhandled exception, missing dependency). 2) Misconfigured command or args in pod spec. 3) Missing ConfigMap/Secret that the app requires. 4) OOMKilled (exit code 137). 5) Failed liveness probe causing restarts. 6) Image built for wrong architecture (amd64 vs arm64). 7) Permission denied (wrong user/filesystem perms).\n\nRemember: MCEP — Missing config/secrets, Command error (wrong entrypoint), Exit code non-zero (app crash), Port conflict. Check logs first! training/library/topics/crashloopbackoff/primer.md crashloopbackoff/d4e5f6a7b8c9 crashloopbackoff medium crashloopbackoff,liveness How can a liveness probe cause CrashLoopBackOff? If the liveness probe is too aggressive (short timeout, low failure threshold) or checks the wrong thing (external dependency), it can restart the container even when the app is healthy but slow to respond. Fix: increase initialDelaySeconds, increase timeoutSeconds, and never make liveness probes depend on external services.\n\nRemember: the most common CrashLoopBackOff causes are: missing environment variables, wrong image tag, insufficient memory limits, and failed health checks (liveness probe killing the container). training/library/topics/crashloopbackoff/primer.md crashloopbackoff/e5f6a7b8c9d0 crashloopbackoff hard crashloopbackoff,debugging How do you debug a container that crashes immediately on startup? 1) Override the entrypoint: kubectl run debug --image= --command -- sleep infinity, then exec in. 2) Check if the image has a shell: kubectl debug -it --image=busybox. 3) Use ephemeral debug containers (kubectl debug -it --image=busybox --target=). 4) Check exit code: 1=app error, 126=permission, 127=command not found, 137=OOM.\n\nExample: kubectl logs pod-name --previous shows logs from the LAST crashed container. Without --previous, you see the current (probably empty) container. training/library/topics/crashloopbackoff/primer.md crashloopbackoff/f6a7b8c9d0e1 crashloopbackoff easy crashloopbackoff,backoff What is the exponential backoff timing in CrashLoopBackOff? Kubernetes waits 10s after the first crash, then doubles: 10s, 20s, 40s, 80s, 160s, capping at 300s (5 minutes). The backoff resets after the container runs successfully for 10 minutes. During backoff, the pod status shows CrashLoopBackOff and the container is not running.\n\nRemember: the most common CrashLoopBackOff causes are: missing environment variables, wrong image tag, insufficient memory limits, and failed health checks (liveness probe killing the container). training/library/topics/crashloopbackoff/primer.md crashloopbackoff/a7b8c9d0e1f2 crashloopbackoff medium crashloopbackoff,exitcodes What do common container exit codes tell you? Exit code 0: success (container completed — wrong for long-running services). 1: general application error. 2: shell misuse. 126: command invoked but not executable (permission). 127: command not found (wrong binary path or missing in image). 137: SIGKILL (OOMKilled or kubectl delete --force). 143: SIGTERM (graceful shutdown).\n\nRemember: exit 0 = success, 1 = general error, 137 = OOMKilled (128+9=SIGKILL), 143 = graceful termination (128+15=SIGTERM). 137 is the most common surprise. training/library/topics/crashloopbackoff/primer.md crashloopbackoff/b8c9d0e1f2a3 crashloopbackoff medium crashloopbackoff,configmap How does a missing ConfigMap or Secret cause CrashLoopBackOff? If a pod spec references a ConfigMap or Secret as an environment variable (envFrom or env.valueFrom) and it does not exist, the container fails to start — kubelet cannot inject the variables. If mounted as a volume with optional: false (default), the pod stays in ContainerCreating, not CrashLoopBackOff. Check kubectl describe for mount errors.\n\nRemember: the most common CrashLoopBackOff causes are: missing environment variables, wrong image tag, insufficient memory limits, and failed health checks (liveness probe killing the container). training/library/topics/crashloopbackoff/primer.md crashloopbackoff/c9d0e1f2a3b4 crashloopbackoff hard crashloopbackoff,init How do failing init containers cause CrashLoopBackOff? Init containers run sequentially before the main container. If an init container crashes, the pod stays in Init:CrashLoopBackOff. Common causes: migration scripts failing, dependency checks timing out, or wrong database credentials in init containers. Debug with kubectl logs -c .\n\nRemember: the most common CrashLoopBackOff causes are: missing environment variables, wrong image tag, insufficient memory limits, and failed health checks (liveness probe killing the container). training/library/topics/crashloopbackoff/primer.md crashloopbackoff/d0e1f2a3b4c5 crashloopbackoff easy crashloopbackoff,prevention What practices help prevent CrashLoopBackOff in production? 1) Health check endpoints that are fast and dependency-free for liveness probes. 2) Graceful degradation when dependencies are unavailable. 3) Proper resource limits based on profiling. 4) Config validation before deploying (check ConfigMaps/Secrets exist). 5) Readiness gates to prevent traffic before app is ready. 6) Always set initialDelaySeconds for liveness probes.\n\nRemember: the most common CrashLoopBackOff causes are: missing environment variables, wrong image tag, insufficient memory limits, and failed health checks (liveness probe killing the container). training/library/topics/crashloopbackoff/primer.md --- ## Wiki Navigation ### Related Content - [CrashLoopBackOff](../../../../library/topics/crashloopbackoff/index.md) (Topic Pack, L1) — CrashLoopBackOff (alias)