Jest "worker encountered 4 child process exceptions" (OOM in CI)
By Daniel Zoghalchali·Latchkey
A Jest worker process crashed repeatedly until Jest gave up. The usual cause is the runner running out of memory: Jest spawns one worker per CPU, and on a many-core CI machine that can exhaust RAM.
What this error means
The run dies mid-way with "Jest worker encountered 4 child process exceptions, exceeding retry limit." There is often no assertion failure - a worker was killed (exit 137 / SIGKILL) by the OOM killer, not by a failing test.
Jest output
Jest worker encountered 4 child process exceptions, exceeding retry limit
at ChildProcessWorker.initialize (node_modules/jest-worker/build/workers/ChildProcessWorker.js)
Common causes
Too many workers for the available RAM
Jest defaults to one worker per core. A 16-vCPU runner spawns ~15 workers; if each loads a heavy module graph, total memory blows past the limit and the kernel kills workers.
A memory leak across tests in a worker
Tests that retain large objects, never tear down servers, or accumulate listeners grow a worker’s heap until it is OOM-killed.
How to fix it
Cap the worker count in CI
Fewer workers means less peak memory. This is the most reliable fix on big runners.
Terminal
# limit workers (an absolute count or a fraction of cores)
jest --maxWorkers=2
# or
jest --maxWorkers=50%
Raise the Node heap and find leaks
Terminal
NODE_OPTIONS=--max-old-space-size=4096 jest --maxWorkers=2
# investigate retained memory
jest --detectLeaks --logHeapUsage
How to prevent it
Pin --maxWorkers in CI rather than inheriting the core count.
Tear down servers, timers, and listeners in afterEach/afterAll.
Use a runner sized for the suite’s real memory footprint.
Frequently asked questions
What causes ""worker ... child process exceptions""?
Jest defaults to one worker per core. A 16-vCPU runner spawns ~15 workers; if each loads a heavy module graph, total memory blows past the limit and the kernel kills workers.
How do I fix "worker ... child process exceptions"?
Fewer workers means less peak memory. This is the most reliable fix on big runners.
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.
