Exit Code 137 Explained: SIGKILL and the OOM Killer in CI
Exit code 137 means a process was terminated by SIGKILL. The number is 128 + 9, where 9 is the signal - and in CI the culprit is almost always the out-of-memory killer.
When a CI step ends with exit code 137, it did not "return" that code - it was killed. Understanding the encoding tells you exactly what happened and why there is usually no stack trace.
The 128 + N encoding
By Unix convention, a process terminated by signal N reports exit code 128 + N. SIGKILL is signal 9, so 128 + 9 = 137. Likewise SIGTERM (15) is 143 and SIGINT (2) is 130. Seeing a code above 128 is your cue that a signal - not the program’s own logic - ended the process.
Why it is almost always OOM in CI
SIGKILL cannot be caught, blocked, or ignored, so the kernel uses it when it must force a process to die immediately. On memory-limited CI runners, the most common source is the cgroup out-of-memory killer reclaiming memory by killing the heaviest process. That is why 137 usually appears with just the word Killed and no traceback.
How to confirm and fix it
- Check the runner’s memory usage around the failure, or the kernel log for an
oom-killline. - Give the job more memory, or reduce peak usage (lower parallelism, cap language heaps).
- Rule out an external watchdog or
timeout --signal=KILLif memory looks fine.
Key takeaways
- Exit code 137 = killed by SIGKILL (128 + 9).
- In CI it is overwhelmingly the out-of-memory killer.
- There is rarely a stack trace because SIGKILL cannot be trapped.
- The fix is mechanical: more memory or lower peak usage.
Frequently asked questions
Can exit 137 happen without running out of memory?
kill -9. But on memory-constrained CI runners, OOM is by far the most likely cause.