jest worker encountered child process exceptions: how to fix

TL;DR

Jest workers crash from resource exhaustion or native module issues. Reduce --maxWorkers, isolate the crashing suite, and check for native bindings that do not survive worker restarts.

Error

Jest worker encountered 4 child process exceptions, exceeding retry limit

Steps

1. Run with --runInBand (single worker). Expected: if it passes, the issue is worker parallelism, not the tests.
2. Halve --maxWorkers (for example --maxWorkers=2). Expected: fewer concurrent workers, fewer crashes.
3. Find the crashing suite: run files one by one until a worker dies. Expected: one suite reproduces it.
4. Check that suite for native modules, huge fixtures, or process.exit calls. Expected: you find the worker-killer.
5. Fix or quarantine that suite, then restore worker count gradually. Expected: full parallelism back with no crashes.

When to use

• child process exceptions in Jest output.
• Crashes that vanish with --runInBand.

When not to use

• Heap OOM with a clear stack (memory skill).
• Failures that reproduce single-threaded (real test bugs).

Tool compatibility

• Jest 27 through 30; --maxWorkers, --runInBand.

Variant phrasings

Jest worker crashed

The short form; same diagnosis.

Jest exceeded retry limit

Workers kept dying; the suite needs isolation.

Why it happens

Workers are child processes with finite memory. A suite that leaks, loads native code unsafely, or just needs more RAM kills its worker, and Jest retries until the limit.

Edge cases

• --maxWorkers=50% is a saner default than the automatic count on big CI machines.
• Native modules (canvas, sharp) are the classic worker killers; mock them in unit tests.
• --detectOpenHandles can reveal what keeps workers alive, at the cost of speed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ybu17xbdjTORXtcEbFTYDw