highIntermediateSymptom-first#pods#exit-code#entrypoint#daemonize

Container exits immediately with exit code 0 — entrypoint daemonizes or returns

Pod restarts repeatedly with exit code 0 and status Completed

Likely source:availabilityconfiguration

Focused incident mode — strips away everything but this runbook.

Symptoms

  • Pod restarts repeatedly with exit code 0 and status Completed
  • Container never stays in Running state
  • kubectl get pods shows CrashLoopBackOff with no error logs

Exit code 0 = 'clean exit', not a failure. Kubernetes restarts it because restartPolicy defaults to Always. Either fix the entrypoint to stay foreground or switch to a Job with restartPolicy Never.

Evidence to grab

Collect these artifacts before you change anything — they prove (or rule out) each cause.

  • Exit code confirmation

    kubectl get pod <pod> -n <namespace> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'

  • Container state history

    kubectl get pod <pod> -n <namespace> -o jsonpath='{.status.containerStatuses[*].state}'

Diagnostic flow

Run the steps in order, marking each claim confirmed or refuted. The evidence you gather feeds the ranked causes below.

Guided decision tree is ready.

Steps with commands, expected output, and pass/fail branches.

Ranked root causes

Evidence checklist

  • Exit code 0 with no crash logs
  • Command in the manifest is a shell script that uses nohup or &

Confirm before fixing

kubectl get pod <pod> -n <namespace> -o jsonpath='{.spec.containers[0].command}'
READ

Read the entrypoint

Fix

kubectl set image deployment/<deploy> <container>=<image>:<fixed>
CHANGE

Deploy a build where the entrypoint runs in the foreground (exec form or tail -f)

Resolution runbook

Apply from top to bottom after the cause is confirmed. Review every command before running it — risk tags are shown on each.

1
kubectl get pod <pod> -n <namespace> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'
READ

Confirm exit code 0

2
kubectl logs <pod> -n <namespace> --previous
READ

Read logs from the completed run

3
kubectl set image deployment/<deploy> <container>=<image>:<foreground-build>
CHANGE

Deploy with an entrypoint that stays in the foreground

Prevention

  • Always run services in the foreground (exec form in Dockerfile, no fork/daemonize).
  • Use a Job with completions:1 for one-shot workloads instead of a Deployment.
  • Add liveness probes to catch processes that exit cleanly but should not.
  • Test the container locally with docker run --rm to confirm it stays alive.

Related runbooks

Same stack, same failure family — worth a skim.

CrashLoopBackOff — container keeps crashing and restartingcritical

kubectl get pods shows CrashLoopBackOff status

KubernetesFoundation4 causes
Open runbook
Job backoffLimitExceeded — retries exhausted, job failed permanentlyhigh

kubectl get job shows Failed status with backoffLimitExceeded

KubernetesFoundation3 causes
Open runbook

Commands marked READ CHANGE DESTRUCTIVE — never run DESTRUCTIVE commands against production data you cannot restore. Copy → verify → execute.