Interactive tool

What that exit code means

Exit codes are the first evidence you get when a container dies, and the most commonly misread. This explains the common ones and teaches the rule behind them, so you can decode a code this page has never heard of.

Runs in your browser · nothing is sent anywhere

Exit code

From kubectl describe pod — the Exit Code in the Last State block.

137SIGKILL — often OOMKilled

128 + 9: killed by SIGKILL. In Kubernetes this is often the container exceeding its memory limit, but a process still running when the termination grace period expires is SIGKILLed too, with the same code. There is no graceful shutdown, so logs typically just stop mid-sentence.

What to do

Confirm with kubectl describe pod — look for Reason: OOMKilled in Last State.
Then determine whether the limit is too low or the application is leaking; the fixes are opposite.

Full troubleshooting page for this →

The rule worth remembering

Exit codes above 128 mean the process was killed by a signal, and the signal number is the code minus 128. So 137 is SIGKILL (9), 143 is SIGTERM (15) and 139 is SIGSEGV (11). Once you know that, most container exit codes decode themselves.

Related troubleshooting

CrashLoopBackOff OOMKilled (exit code 137)

What an exit code is

Every process that finishes hands back a number. Zero means it succeeded; anything else means it did not. Docker and Kubernetes record that number when a container stops, and it is usually the first piece of evidence you get.

Codes above 128 mean something different in kind: the process did not choose to exit at all, it was terminated by a signal. That is why reading them needs a rule rather than a lookup table.

Using it

Type the code. If it is one of the common ones you get the cause and what to check; if it is not, the arithmetic still applies and the rule is shown.

Get the code with kubectl describe pod <pod> | grep -A3 'Last State' or docker inspect <container> --format '{{.State.ExitCode}}'.

What this checks

What a container or process exit code means, including the 128 + signal rule behind 137 and 143.

What it cannot know

Who sent the signal. 137 is SIGKILL from the kernel's OOM killer, kubelet, docker stop's timeout or a person, and the number alone cannot say which.

Check it for real

docker inspect --format '{{.State.ExitCode}} {{.State.OOMKilled}}' <container>
kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[0].lastState.terminated}'

Both report the exit code together with whether the out-of-memory killer was involved: OOMKilled true in Docker, reason OOMKilled in Kubernetes. Kubernetes: container states

Why 128, and what the code cannot tell you

The convention is that an exit status above 128 encodes “terminated by signal N” as 128 + N. So 137 is 128 + 9 (SIGKILL), 143 is 128 + 15 (SIGTERM), 139 is 128 + 11 (SIGSEGV), 130 is 128 + 2 (SIGINT). That rule decodes codes no table lists.

What the code cannot tell you is who sent the signal. A 137 is consistent with hitting a memory limit, with an orchestrator stopping the container, and with a supervisor inside the image killing its child — which is why OOMKilled has to be read beside it, and why treating every 137 as out-of-memory sends you tuning a limit that was never involved.

A 143 during a rollout is usually a clean shutdown. A 137 during a rollout usually means the process did not finish inside terminationGracePeriodSeconds and was killed after the polite request expired.

Questions people ask about this

Why did my container exit with 137?

137 is 128 + 9, and signal 9 is SIGKILL: something terminated the process outright rather than asking it to stop.

The code alone does not say what. Read the reason beside it — Reason: OOMKilled means the OOM killer ended it, over its memory limit or with the node out of memory; any other reason means the SIGKILL came from somewhere else, such as an orchestrator stopping the container or a supervisor inside the image. Treating every 137 as out-of-memory sends you tuning a limit that was never involved.

kubectl describe pod <pod> | grep -A3 'Last State'

If it was the limit, the resource calculator is the next stop, and the OOMKilled page covers the causes.

What is the difference between 137 and 143?

143 is 128 + 15, or SIGTERM — a request to shut down that the process actually received. 137 is SIGKILL, which cannot be caught or ignored.

Kubernetes sends SIGTERM first, waits terminationGracePeriodSeconds (30 by default), then sends SIGKILL. So a 143 on its own usually means a clean shutdown, while a 137 during a rollout often means the process did not finish inside the grace period.

Why is it 128 plus the signal number?

It is a shell convention: an exit status above 128 encodes “terminated by signal N” as 128 + N. That is the whole rule, and it decodes codes this page does not list — 130 is 128 + 2 (SIGINT, Ctrl-C), 141 is 128 + 13 (SIGPIPE, writing to a closed pipe).

What does 139 mean?

128 + 11, or SIGSEGV: a segmentation fault. The process reached for memory it was not allowed to touch. This is a bug or a mismatched native library rather than a resource limit, so raising memory will not fix it — the logs and a core dump will tell you more than the exit code does.

What about exit code 0 or 1?

Neither involves a signal. 0 is success — worth knowing because a container that exits 0 and restarts is usually a process that was never meant to be long-running. 1 is the application returning failure itself, so the logs will say more than the code can.

Did this get you to an answer?

No text box on purpose — please do not paste production logs anywhere

Something wrong or out of date? Report it