## TL;DR

`--maxWorkers` trades speed for memory. On CI, set it to 50-75% of available CPUs, lower if workers crash, and measure rather than guessing.

## Error

```text
(Not an error; a tuning task. Symptoms: Jest is slow with too few workers, or crashes with too many.)
```

## Steps

1. Find the runner's CPU count (`nproc`). Expected: the ceiling.
2. Start with `--maxWorkers=50%`. Expected: a safe baseline.
3. Time the suite. Expected: a number to compare.
4. Try 75% and 100%; keep the fastest stable setting. Expected: measured optimum.
5. If workers crash at high counts, drop back and fix the memory hogs. Expected: stability over raw speed.

## When to use

- Jest too slow or too crashy in CI.
- New CI runner size.

## When not to use

- Local runs (use the default).
- `--runInBand` debugging (single worker by design).

## Tool compatibility

- Jest 27 through 30; `--maxWorkers`.

## Variant phrasings

### Jest maxWorkers best value

Measured per runner; 50% is the starting guess.

### Jest CI performance tuning

The broader task; workers are the biggest knob.

## Why it happens

Too few workers waste CPUs; too many exhaust RAM and crash. The optimum depends on the runner and the suite's memory profile.

## Edge cases

- `--maxWorkers` in CI config files is better than CLI flags for consistency.
- Memory-heavy suites want fewer workers than CPU count suggests.
- `--workerIdleMemoryLimit` complements worker tuning by recycling fat workers.

## Provenance

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