Jest runs tests across worker processes; when total worker memory exceeds the runner RAM, a worker is OOM-killed and Jest reports it failed unexpectedly. High --maxWorkers is the usual driver.
What this error means
Tests fail with Jest worker encountered 4 child process exceptions or ran out of memory. Lowering --maxWorkers or using a larger runner clears a one-off spike; steadily climbing memory across files suggests a leak.
shell
Jest worker encountered 4 child process exceptions, exceeding retry limit
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
Common causes
Too many workers for the runner RAM
Jest defaults to many workers; each holds its own heap, and the sum can exceed available memory.
A memory leak in the test setup
Unclosed handles or accumulating module state grow each worker until it is killed; that is a code fix.
Run with --detectLeaks / --logHeapUsage to find growth.
Close DB/server handles in afterAll to stop accumulation.
How to prevent it
Set --maxWorkers to the runner size.
Monitor heap usage per worker in CI.
Right-size memory for large test suites.
Frequently asked questions
What causes "Jest worker OOM"?
Jest defaults to many workers; each holds its own heap, and the sum can exceed available memory.
How do I fix Jest worker OOM?
Reduce concurrency so total worker memory fits.
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.