## TL;DR

Each Jest worker has a heap limit, and large suites exceed it. Raise the limit with `NODE_OPTIONS`, reduce workers so each gets more room, and find the suite that leaks.

## Error

```text
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
```

## Steps

1. Run with `NODE_OPTIONS=--max-old-space-size=4096 npx jest`. Expected: the run gets further.
2. Reduce workers: `npx jest --maxWorkers=2`. Expected: fewer workers means more memory each.
3. Find the leaking suite: run files individually and watch memory. Expected: one file grows without bound.
4. Common leaks: huge snapshots, unclosed servers, module-level caches. Fix the suite. Expected: memory returns to baseline.
5. For permanently large suites, split the CI job by path. Expected: each job fits in memory.

## When to use

- `heap out of memory` naming node/Jest.
- Suites with big snapshots or many files.

## When not to use

- Worker child-process exceptions without OOM (worker skill).
- Cypress heap OOM (different process model).

## Tool compatibility

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

## Variant phrasings

### Jest ran out of memory in CI

CI runners have less RAM; the same suite passes on a laptop.

### Allocation failed in Jest worker

The worker-specific form; reduce workers first.

## Why it happens

Workers share the machine's RAM. Big suites plus many workers exceed it, and the default heap limit is modest.

## Edge cases

- `--logHeapUsage` shows per-suite memory; use it to find the leak.
- `--workerIdleMemoryLimit` (Jest 29+) restarts workers that grow too big automatically.
- Snapshot files of many megabytes are a common hidden cause.

## Provenance

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