Exit Code 137 (Out of Memory) on GitLab CI - Causes and Fixes
By Kaveh Alemi·Latchkey
Exit Code 137 (Out of Memory) is an infrastructure failure, not a bug in your code - here is the GitLab CI-specific fix.
What this error means
A step or job ends with exit code 137 and often just the word Killed. The process received SIGKILL - on CI runners, almost always the out-of-memory killer.
GitLab CI log
Killed
Process completed with exit code 137.
Common causes
The job exceeded the available memory
Bundlers, compilers, and test suites can spike past the runner memory ceiling; the kernel OOM killer terminates the heaviest process with SIGKILL.
A container/heap limit is too low
An explicit memory limit (or a too-small language heap) makes the process hit the wall sooner.
How to fix it
Give it more resources on GitLab CI
Run the job on a runner with more resources - tag a larger runner, or for the Kubernetes executor set KUBERNETES_MEMORY_REQUEST / KUBERNETES_MEMORY_LIMIT.
Reduce peak usage
Lower build/test parallelism and cap language heaps (e.g. NODE_OPTIONS=--max-old-space-size) below the runner limit.
How to prevent it
Right-size GitLab CI runners/agents for the job.
Cache dependencies to cut time, memory pressure, and network calls.
Use self-healing runners that retry transient and mechanical failures automatically.
Frequently asked questions
What causes "Exit code 137 on GitLab CI"?
Bundlers, compilers, and test suites can spike past the runner memory ceiling; the kernel OOM killer terminates the heaviest process with SIGKILL.
How do I fix Exit code 137 on GitLab CI?
Run the job on a runner with more resources - tag a larger runner, or for the Kubernetes executor set KUBERNETES_MEMORY_REQUEST / KUBERNETES_MEMORY_LIMIT.
Can Latchkey fix this automatically?
Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.
