Exit code 1: The application exited with a general error

Exit code 1 is the generic failure status. It means the application decided to fail and said so, which makes it the one exit code where the logs are guaranteed to be the right place to look.

Applies to: All Kubernetes versions, Linux nodes

What it means

One is the conventional catch-all failure status on Unix. Nothing in Kubernetes or the container runtime generates it — the process chose it, either explicitly or through a runtime's default handling of an uncaught error. That is genuinely useful information: unlike 137 or 139, where the process was killed from outside and may have had no chance to explain itself, a 1 means the program reached a point where it decided to stop and almost certainly wrote something before doing so. Interpreting it further requires the application's own conventions, because 1 carries no standard meaning beyond failure.

Most common causes

• A required environment variable or configuration value is missing, and the application validates its config at startup.
• A dependency the application connects to at startup — a database, a cache, a message broker — is unreachable.
• An uncaught exception in a runtime that maps unhandled errors to exit 1, which includes Node.js, Python, and Java under most launchers.
• A configuration file that is present but malformed.
• A migration or schema check that failed.
• The application ran fine and exited 1 deliberately because a health check it performs itself did not pass.

How to diagnose it

1. Read the previous container's logs, not the current one: kubectl logs POD --previous. A process that chose exit 1 almost always logged why.
2. Check the last few lines rather than the first — the failure is at the end.
3. Confirm the environment the container actually received: kubectl exec is unavailable on a dead container, so check the resolved spec with kubectl get pod POD -o yaml and the referenced ConfigMaps and Secrets.
4. If the logs are empty, the runtime may be buffering stdout. Set the language's unbuffered flag — PYTHONUNBUFFERED=1 for Python, for example — so the failure is actually written before the process dies.
5. Run the same image locally with the same configuration to reproduce it outside the cluster.

How to fix it

1. Fix whatever the logs report. There is no Kubernetes-side fix for exit 1 — the cluster did exactly what it was asked.
2. If a startup dependency is not ready, add retry with backoff in the application rather than letting it fail on first attempt during a rollout.
3. Add explicit configuration validation with a clear message, so the next occurrence names the missing value instead of producing a stack trace.
4. Disable output buffering in containerised runtimes so short-lived failures leave a log behind.

Notes

A container that exits 1 quickly and repeatedly under restartPolicy: Always reaches CrashLoopBackOff within seconds, and from that moment the current container's logs are empty. The --previous flag is not optional here.

Related

• CrashLoopBackOff — Repeated restarts with increasing delay
• Exit code 2 — Misuse of a shell builtin, or an application-specific error

Sources

• Kubernetes documentation — Debug Running Pods
• Kubernetes documentation — Pod Lifecycle: container states
• GNU Bash Reference Manual — Exit Status