Skip to content
Latchkey

GitLab CI "Job failed: exit status 137" (OOM) in CI

Exit status 137 is 128 + signal 9 (SIGKILL): the job was killed, almost always by the out-of-memory killer or a container memory limit. The process used more memory than the runner or cgroup allowed.

What this error means

The job ends abruptly with "Cleaning up project directory ... ERROR: Job failed: exit status 137". The killed step often produced no error of its own.

GitLab Runner
Cleaning up project directory and file based variables
ERROR: Job failed: exit status 137

Common causes

The job exceeded the memory limit

A build or test step allocated more memory than the container or host allowed, so the kernel killed it with SIGKILL.

A container memory cap set on the runner

A memory limit in the Docker executor config caps the container; exceeding it triggers an OOM kill.

How to fix it

Reduce the job's memory use or raise the limit

  1. Lower parallelism or batch size in the memory-hungry step.
  2. Raise the container/runner memory limit if the work genuinely needs it.
  3. Re-run and watch peak memory.
.gitlab-ci.yml
test:
  variables:
    JEST_WORKERS: "2"   # fewer workers, less peak memory
  script: npx jest --maxWorkers=$JEST_WORKERS

Increase the Docker executor memory limit

Raise the memory allotment in the runner config so the container is not capped below what the job needs.

config.toml
# config.toml
[runners.docker]
  memory = "4g"

How to prevent it

  • Profile peak memory and size runners accordingly.
  • Cap parallelism in memory-heavy build/test steps.
  • Alert on 137 exits so OOM trends are visible.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →