What does exit code 1 mean in Kubernetes?

It means the application process returned status 1: a generic, app-defined error. Kubernetes did not kill the container (that would be 137 or 143); the program decided to exit. The reason is in the application logs, not in cluster state.

How is exit code 1 different from 137 and 143?

Codes above 128 encode signals: 137 is SIGKILL (OOM kill or force-kill), 143 is SIGTERM (graceful stop). Code 1 is below 128, so no signal was involved: the app itself chose to exit with an error status.

Why do I get exit code 1 with no logs at all?

The process died before logging, or it logs to a file instead of stdout/stderr. Verify with --previous first, then check the logging configuration: kubectl logs only ever sees the standard streams of the container's main process.

Can a wrong command in the pod spec cause exit code 1?

Yes. If command/args override the image ENTRYPOINT/CMD incorrectly, many programs print usage information and exit 1. A truly missing binary gives 127 and a non-executable one 126, so exact code 1 suggests the binary ran but rejected its invocation.

Should my app exit 1 when a dependency is down?

Crash-on-boot is legitimate (Kubernetes will back off and retry), but it makes startup ordering fragile and noisy. Retrying with backoff inside the app, or gating with an initContainer or readiness checks, usually produces calmer rollouts.

Error reference

Kubernetes Exit Code 1: Finding the Real Application Error

Updated July 27, 2026

In short

Exit code 1 means the application itself exited with a generic error. Kubernetes is only the messenger. Unlike 137 (SIGKILL) or 143 (SIGTERM), there is no infrastructure story here: the process ran, hit a problem it considered fatal, and returned 1. The answer is in the application's own output: run kubectl logs <pod-name> --previous to read the crashed container's logs. Typical culprits are an unhandled exception at startup, a missing env var or config file, a bad CLI flag, or an unreachable dependency.

start here

kubectl logs <pod-name> --previous --tail=50

Diagnosis

Causes at a glance

Cause	How to recognize it	Fix
Unhandled exception at startup	Logs end in a stack trace	Fix the code path; reproduce by running the image locally
Missing env var or config file	Logs show "required variable", "no such file", or a config parse error	Check env, ConfigMap mounts, and Secret keys against what the app expects
Bad command-line flag or argument	Logs show usage/help text or "unknown flag"	Fix command/args in the pod spec; check ENTRYPOINT vs command semantics
Dependency unreachable at boot	Logs show connection refused/timeout to a DB, queue, or API	Fix the address or credentials; add retries instead of exiting
App logs to a file, not stdout	Exit 1 with completely empty logs	Configure the app to log to stdout/stderr so kubectl logs sees it

Why exit code 1 is not a Kubernetes error

Exit codes below 128 come from the process itself, not from a signal. 1 is the catch-all "something went wrong" status most languages and CLIs return for any uncaught error, which is precisely why it carries no diagnostic value on its own. Kubernetes behaves correctly here: it restarts the container per restartPolicy, and repeated failures become CrashLoopBackOff.

So the debugging posture flips: stop inspecting Kubernetes and start reading the application's own last words.

Step 1

Step 1: read the previous container logs

The crashed container's output is retained and readable with --previous. In the large majority of exit-1 cases, the stack trace or fatal log line is right there.

kubectl logs <pod-name> --previous --tail=100
# multi-container pods:
kubectl logs <pod-name> -c <container-name> --previous

Step 2

Step 2: check what command actually ran

A pod spec command replaces the image ENTRYPOINT and args replaces CMD: a common source of subtly wrong invocations that make apps print usage text and exit 1. Compare the effective command against what the image expects.

kubectl get pod <pod-name> -o jsonpath='{.spec.containers[0].command} {.spec.containers[0].args}'
# what the image itself defines:
docker inspect <image> --format '{{.Config.Entrypoint}} {{.Config.Cmd}}'

Step 3

Step 3: verify env and mounted config

Apps that validate config at boot exit 1 the moment a variable is missing or a file fails to parse. Dump what the container actually received (not what you think the manifest says) and check mounted paths exist.

kubectl exec <pod-name> -- env | sort
kubectl exec <pod-name> -- ls -la /etc/config /etc/secrets
# if it dies too fast to exec into, run the image with a shell:
kubectl run debug --rm -it --image=<image> --command -- sh

Step 4

Step 4: reproduce outside Kubernetes

Running the same image with the same env locally removes every cluster variable at once. If it exits 1 locally too, it is purely an app/config problem; if it runs locally but dies in the cluster, the difference is env, mounts, network reachability, or the security context.

docker run --rm -e DATABASE_URL=... -e LOG_LEVEL=debug <image>
echo $?   # same exit code semantics as in the cluster

When the logs are empty

An exit 1 with no output usually means the app writes logs to a file inside the container instead of stdout/stderr: the container-native convention kubectl logs depends on. Reconfigure the logger to write to stdout, or as a stopgap symlink the log file to /dev/stdout the way the official nginx image does.

Beyond the one-off fix

Exit code 1 debugging always ends at the same question: what does this build expect that it is not getting? When AI agents write code and ship config, the expectation and the environment can drift in a single afternoon. Nexus ties every agent-authored change (code, env vars, manifests) to an auditable trail, so "which change introduced the config this app now requires" is a lookup, not an archaeology dig.

Explore Swfte Nexus

Common questions

What does exit code 1 mean in Kubernetes?: It means the application process returned status 1: a generic, app-defined error. Kubernetes did not kill the container (that would be 137 or 143); the program decided to exit. The reason is in the application logs, not in cluster state.
How is exit code 1 different from 137 and 143?: Codes above 128 encode signals: 137 is SIGKILL (OOM kill or force-kill), 143 is SIGTERM (graceful stop). Code 1 is below 128, so no signal was involved: the app itself chose to exit with an error status.
Why do I get exit code 1 with no logs at all?: The process died before logging, or it logs to a file instead of stdout/stderr. Verify with --previous first, then check the logging configuration: kubectl logs only ever sees the standard streams of the container's main process.
Can a wrong command in the pod spec cause exit code 1?: Yes. If command/args override the image ENTRYPOINT/CMD incorrectly, many programs print usage information and exit 1. A truly missing binary gives 127 and a non-executable one 126, so exact code 1 suggests the binary ran but rejected its invocation.
Should my app exit 1 when a dependency is down?: Crash-on-boot is legitimate (Kubernetes will back off and retry), but it makes startup ordering fragile and noisy. Retrying with backoff inside the app, or gating with an initContainer or readiness checks, usually produces calmer rollouts.