Container exit code 137 is often misdiagnosed as an out-of-memory (OOM) issue, leading teams to prematurely scale up resources. In this real-world debugging case, a production container repeatedly exited with code 137, and the initial reaction was to assume OOM. However, a closer look at the exit code semantics reveals that 137 equals 128 plus signal 9 (SIGKILL), which can be triggered by various conditions, including host reboots. The author systematically checked host logs and found that the underlying server was rebooting unexpectedly, causing all containers to be killed. This case underscores the importance of understanding Linux exit code conventions and checking host-level events before jumping to conclusions. For DevOps and SRE teams, this is a valuable reminder to correlate container exit codes with system-level logs and metrics to avoid wasted effort and misconfigured infrastructure.
A production container kept exiting with code 137, initially blamed on OOM. The author breaks down the exit code semantics (128+9=SIGKILL) and discovers the host was rebooting, not the container being OOM-killed. This highlights the importance of checking host-level events when debugging container exits.