Exit code 137 is 128 + 9 — the container was killed by signal 9, SIGKILL. That signal can't be caught or ignored, so the process gets no chance to log why. Here's how to find the actual cause.
There are two common reasons a container exits 137, and they call for different fixes. The steps below tell them apart.
This is the most common cause of 137 in both Docker and Kubernetes: the container tried to use more memory than its limit allowed, so the kernel's OOM killer (or the container runtime enforcing a cgroup limit) killed it.
Docker: ask Docker directly — it records whether the exit was an OOM kill:
docker inspect <container> --format '{{.State.OOMKilled}}'
If that prints true, it's confirmed: raise the container's memory limit (docker run --memory) or reduce what the process allocates.
Kubernetes: describe the pod and look at the last terminated state:
kubectl describe pod <pod>
Look for Last State: Terminated with Reason: OOMKilled under the container's status. Fix by raising resources.limits.memory in the pod spec, or reducing memory usage.
On the host itself, the kernel also logs OOM kills, which is useful if you don't have docker inspect output (e.g. after the container was removed):
dmesg | grep -i "killed process" # or, on systemd hosts: journalctl -k | grep -i "oom"
If OOMKilled is false (or absent), the more likely cause is a graceful-shutdown timeout: something sent the container a stop request, it didn't exit in time, and the runtime escalated to SIGKILL.
docker stop sends SIGTERM, waits 10 seconds by default (-t/--time to change it), then sends SIGKILL if the process is still running.SIGTERM, waits terminationGracePeriodSeconds (default 30s), then sends SIGKILL.If this is the cause, either make your process exit faster on SIGTERM (many language runtimes ignore it by default unless you add a handler — e.g. Node's default doesn't forward it to child processes in some setups, Python needs a signal.signal(SIGTERM, ...) handler to shut down cleanly), or extend the grace period if the slow shutdown is expected and safe.
docker inspect or kubectl describe anymore (container already removed, cluster rotated), there is no way to recover which of the two happened after the fact — plan to check next time it occurs.Exit code 143 (SIGTERM) is the graceful-stop signal that precedes a 137 escalation — if you see 143 instead, the process already exited cleanly when asked and no kill was needed. For every other exit code and signal, use the lookup tool below.