Kubernetes "Init:CrashLoopBackOff" / "Init:Error" - Fix Init Containers
Init containers run to completion, in order, before the main containers start. When one fails or loops, the pod is stuck in Init:Error/Init:CrashLoopBackOff and the app containers never run.
What this error means
A pod shows STATUS: Init:Error or Init:CrashLoopBackOff (often Init:0/1). The main containers are never created because an init container has not completed successfully.
NAME READY STATUS RESTARTS AGE
api-... 0/1 Init:CrashLoopBackOff 4 2mCommon causes
Init step exits non-zero
A migration, config fetch, or wait-for-dependency init container fails (DB unreachable, bad command, missing config), so it never completes and blocks the pod.
Dependency the init waits on is not ready
An init container that blocks until a service is reachable loops while that dependency is down or misconfigured.
How to fix it
Read the failing init container’s logs by name
You must target the init container explicitly with -c; plain kubectl logs reads the app container, which has not started.
kubectl get pod <pod> -o jsonpath='{.spec.initContainers[*].name}'; echo
kubectl logs <pod> -c <init-container> --previousFix the init step or its dependency
- If the init runs a migration/command, fix the error it logs and re-deploy.
- If it waits on a dependency, make that dependency reachable or correct the host/port it checks.
- Ensure any config/Secret the init needs exists in the namespace first.
How to prevent it
- Keep init containers idempotent and well-logged so failures are easy to trace.
- Make wait-for-dependency inits bounded with a clear failure message.
- Apply config/Secrets the init depends on before the workload.