## 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

```text
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