Skip to content
Latchkey

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.

kubectl get/describe
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: 1

Common 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

  1. Find the failing init container in kubectl describe pod <pod>.
  2. Read its logs: kubectl logs <pod> -c <init-container>.
  3. Fix the underlying cause (dependency reachable, correct command, present inputs).
Terminal
kubectl describe pod <pod>
kubectl logs <pod> -c wait-for-db

Make the init robust

  1. Give wait-for-dependency inits a sane timeout and clear failure message.
  2. Ensure any file/secret the init mounts is present before the pod starts.
  3. 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.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →