Runner Exit Code 137 (OOM Killed) - Out-of-Memory in CI

By Daniel Zoghalchali·Latchkey

Exit code 137 is 128 + 9 - the process received SIGKILL. On a memory-limited CI runner that is almost always the out-of-memory killer terminating the heaviest process.

What this error means

A step ends abruptly with Killed and the runner reports exit code 137. There is rarely a stack trace because SIGKILL cannot be caught or cleaned up after. Re-running on a larger runner usually passes unchanged.

CI log

Killed
##[error] Process completed with exit code 137.

Common causes

The job exceeded the runner memory ceiling

A compile, bundler, test suite, or data load spiked past the available RAM. The kernel cgroup OOM killer then terminates the largest process with an uncatchable SIGKILL.

A cgroup or container memory limit is too low

When the runner runs inside a container with --memory/-m set, exceeding that limit triggers the same kill at exit 137 even if the host has free RAM.

How to fix it

Give the job more memory

Run on a larger runner with more RAM.
Raise or remove an explicit container --memory limit if one is set.
Cap language heaps below the runner ceiling (e.g. NODE_OPTIONS=--max-old-space-size=4096, -Xmx for the JVM).

Confirm it was memory, then reduce peak usage

Check the kernel log for the OOM event, then lower the high-water mark.

Terminal

dmesg -T | grep -i -E 'killed process|out of memory'
# then lower parallelism, e.g.
make -j2   # instead of -j$(nproc)

How to prevent it

Right-size runners for memory-heavy builds.
Set language heap limits relative to the runner memory.
Watch peak memory in CI so you catch growth before it OOMs.

Frequently asked questions

Is exit 137 always out of memory?

It means the process got SIGKILL. On memory-limited CI runners that is overwhelmingly the OOM killer, but it can also be an external watchdog or timeout --signal=KILL. Check the runner memory metrics or kernel log to confirm.

References

GitHub Actions documentation