Kubernetes "Init:Error" / "Init:CrashLoopBackOff" - Fix Init Containers in CI
Init containers run to completion in order before the app containers start. One of them exited non-zero, so Kubernetes holds the pod in Init:Error (or retries it as Init:CrashLoopBackOff) and the main app never runs.
What this error means
The pod is stuck at Init:Error or Init:CrashLoopBackOff; kubectl describe pod names the failing init container and kubectl logs <pod> -c <init> shows why it exited. The deploy in CI waits forever for readiness.
NAME READY STATUS RESTARTS AGE
app-7d9c-abcde 0/1 Init:CrashLoopBackOff 4 3m
# describe: Init Containers: wait-for-db State: Terminated Reason: Error Exit Code: 1Common causes
Init logic failed
The init container's job -- a migration, a wait-for-dependency probe, a config fetch -- exited non-zero because the dependency was unreachable or the command itself errored.
Bad command, image, or missing input
A wrong entrypoint, a missing mounted file/secret, or an unreachable endpoint the init waits on makes it fail before the app can start.
How to fix it
Read the failing init container logs
- Find the failing init container in
kubectl describe pod <pod>. - Read its logs:
kubectl logs <pod> -c <init-container>. - Fix the underlying cause (dependency reachable, correct command, present inputs).
kubectl describe pod <pod>
kubectl logs <pod> -c wait-for-dbMake the init robust
- Give wait-for-dependency inits a sane timeout and clear failure message.
- Ensure any file/secret the init mounts is present before the pod starts.
- Verify the init image and command run correctly outside the cluster.
How to prevent it
- Keep init containers idempotent with explicit timeouts.
- Ensure dependencies the init waits on are actually reachable in the target namespace.
- On Latchkey, self-healing managed runners auto-retry transient deploy steps so an init that fails only because a dependency was briefly unreachable does not red the pipeline.