Skip to content
Latchkey

CircleCI "Received \"killed\" signal" - Fix OOM in Jobs

A process in your job was killed by the OS - almost always the out-of-memory killer. The job exceeded the RAM of its resource class, so the container/VM terminated the process.

What this error means

A build or test step dies abruptly with Received "killed" signal, often after a memory-heavy step (bundling, compiling, a big test suite). It frequently passes on a larger resource class with no code change.

job log
Received "killed" signal
# or in a Node step
<--- Last few GCs --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Common causes

Resource class too small for the workload

The default medium Docker class has limited RAM. A memory-hungry build (webpack, tsc, large test parallelism) exceeds it and the kernel OOM-kills the process.

Runtime heap not aligned to the container

Node or the JVM may size its heap from host memory, not the container limit, then overcommit and get killed.

Memory leak or unbounded parallelism

Running too many workers, or a leak in the build, grows resident memory past the limit even on a larger class.

How to fix it

Raise the resource class

Give the job more RAM by moving up a class - the fastest unblock.

.circleci/config.yml
jobs:
  build:
    docker:
      - image: cimg/node:20.11
    resource_class: large   # was medium
    steps: [checkout, { run: npm run build }]

Cap the runtime heap to the container

.circleci/config.yml
- run:
    name: Build
    command: NODE_OPTIONS=--max-old-space-size=3072 npm run build

Reduce parallelism / memory pressure

  1. Lower test or build worker counts to fit the class.
  2. Stream or chunk large data instead of loading it all in memory.
  3. Profile peak memory and right-size the class to it.

How to prevent it

  • Right-size the resource class to the job’s real peak memory.
  • Pin runtime heap flags to the container, not host memory.
  • Watch for memory growth as suites and bundles get larger.

Frequently asked questions

What causes ""Received \"killed\" signal""?
The default medium Docker class has limited RAM. A memory-hungry build (webpack, tsc, large test parallelism) exceeds it and the kernel OOM-kills the process.
How do I fix "Received \"killed\" signal"?
Give the job more RAM by moving up a class - the fastest unblock.
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.

Related guides

References

Latchkey auto-heals failures like this one - detected, fixed, and retried without you. Start free → 30-day trial · No credit card