## TL;DR

This means Jest's worker processes kept crashing (usually out of memory, or a native module segfaulting) and jest-worker gave up retrying. Re-run the failing file with `--runInBand` first to see the real underlying error, then fix the resource problem: give Node more heap, run fewer workers, or recycle workers with `--workerIdleMemoryLimit`.

## Error

```text
Jest worker encountered 4 child process exceptions exceeding retry limit
```

## Steps

1. Re-run just the failing test file with `--runInBand`: `npx jest path/to/test --runInBand`. Expected: the actual crash (often a heap-out-of-memory error or a native stack trace) prints instead of the generic worker message.
2. If it is heap exhaustion, raise Node's memory limit: `NODE_OPTIONS=--max-old-space-size=4096 npx jest`. Expected: workers stop dying mid-suite; raise the number further for very large suites.
3. If the machine is oversubscribed, cut parallelism: `npx jest --maxWorkers=2`. Expected: the suite runs slower but completes without worker crashes.
4. On Jest 29.3 or newer, recycle workers before they bloat: `npx jest --workerIdleMemoryLimit=1GB`. Expected: long suites stop accumulating memory across test files.
5. If one file always kills its worker, suspect native modules (image, canvas, or sqlite bindings) and update them; run that file alone to confirm. Expected: the isolated file passes, or shows the native crash clearly.

## When to use

- The output is exactly "Jest worker encountered N child process exceptions exceeding retry limit".
- The suite passes file-by-file but fails on a full parallel run.
- You see heap-out-of-memory errors or segfaults when running with --runInBand.

## When not to use

- The error is "Call retries were exceeded" (the task threw instead of the worker crashing; nearby but different fix path).
- A single test fails deterministically (fix the test, not the workers).
- You are on Jest 27 or older, where --workerIdleMemoryLimit does not exist (use --runInBand or upgrade).

## Tool compatibility

- Jest 27 through 30, with the bundled jest-worker.
- `--workerIdleMemoryLimit` needs Jest 29.3 or newer.
- Node.js 16 or newer for NODE_OPTIONS heap tuning.

## Variant phrasings

### jest worker encountered 2 child process exceptions

Same error with a different retry count. The number is how many crashes jest-worker tolerated before giving up.

### jest workers keep crashing

Usually the same underlying cause: worker heap exhaustion on large suites, or one leaky test file taking the worker down with it.

### jest worker farm out of memory

The heap variant. Raise the limit with NODE_OPTIONS and confirm with --runInBand.

## Why it happens

Jest runs test files in child worker processes for parallelism. When a worker dies (most often the V8 heap fills on a big suite, or a native addon segfaults), jest-worker restarts it and retries. After a few crashes it concludes the environment is broken and aborts with this message instead of looping forever.

## Edge cases

- `--runInBand` hides parallelism-only crashes (port conflicts, shared file writes); if it passes in band but fails parallel, suspect shared state, not memory.
- Setting `--maxWorkers` above your CPU count in CI, especially in small containers, is the most common trigger; `--maxWorkers=50%` is a good starting point.
- Heap flags in jest config do not raise the worker heap; the flag must come through NODE_OPTIONS in the environment.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_QMWMapedtY28vQqkpYA-uQ