Exit code 0: The process exited successfully

Exit code 0 means the container's main process finished without error. Under a Job that is success. Under a Deployment it produces a restart loop, because a pod that is supposed to run forever is not supposed to finish.

Applies to: All Kubernetes versions, Linux nodes

What it means

Zero is the conventional success status on Unix: the process ran and reported no error. In Kubernetes the code itself is unambiguous, but its consequences depend entirely on the pod's restartPolicy. Under Always, which is the default and is what Deployments, ReplicaSets, StatefulSets and DaemonSets use, a container that exits 0 is restarted anyway — the policy makes no distinction between success and failure. Under OnFailure it is left alone. Under Never the pod moves to Succeeded. So the same exit code produces a clean completion in one workload type and an endless restart loop in another, which is why 0 turns up in CrashLoopBackOff investigations at all.

Most common causes

• A batch task finished its work. This is the intended outcome for a Job.
• A long-running service was deployed as a Deployment but its process exits after doing one unit of work.
• A server that daemonises into the background, leaving the foreground process to exit immediately with 0.
• A shell entrypoint that runs a command and then ends, rather than exec-ing the real process.
• A process that received SIGTERM, handled it, and chose to exit 0 rather than 143 — this is legitimate and common in well-written servers.

How to diagnose it

1. Read the exit code and reason together: kubectl describe pod POD under Last State.
2. Determine what owns the pod: kubectl get pod POD -o jsonpath='{.metadata.ownerReferences[*].kind}'. A ReplicaSet owner plus exit 0 means the workload type is wrong.
3. Read the logs to see whether the process did its work or returned immediately: kubectl logs POD --previous.
4. Check whether the entrypoint backgrounds anything — a process that forks and exits looks identical to one that completed.

How to fix it

1. Move genuine batch work to a Job or CronJob, where exiting 0 is treated as success.
2. Run servers in the foreground. Nearly every daemon has a flag that prevents it from detaching.
3. Use exec in shell entrypoints so the real process becomes PID 1 rather than a child of a shell that will exit.
4. If a process exits 0 in response to SIGTERM during a rollout, nothing is wrong — filter it out of failure alerting rather than changing the application.

Notes

A container that exits 0 immediately on every start still produces CrashLoopBackOff, and the logs will look completely clean. This combination — a healthy-looking log and a crash loop — is one of the more confusing things Kubernetes presents, and exit code 0 is the tell.

Related

• Completed — All containers exited successfully
• CrashLoopBackOff — Repeated restarts with increasing delay

Sources

• Kubernetes documentation — Pod Lifecycle: restart policy
• Kubernetes documentation — Jobs
• GNU Bash Reference Manual — Exit Status