cypress out of memory on large test runs

Not specified by the original author.

TL;DR

Cypress runs the browser and the test runner in one process tree, and large suites exhaust the heap. Raise the Node memory limit, split the run into smaller chunks, and look for specs that leak memory across tests.

Error

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

Steps

1. Confirm it is Cypress and not the app: the crash message names the Cypress process, and small specs pass. Expected: you rule out the application.
2. Raise the memory limit for the Cypress process: NODE_OPTIONS=--max-old-space-size=4096 npx cypress run. Expected: the run gets further before any crash.
3. Split the suite: run specs in groups (--spec "cypress/e2e/a/**", then b/**). Expected: each chunk fits comfortably in memory.
4. Find leaking specs: run each spec file alone and watch memory; a spec whose memory never drops between tests is the culprit. Expected: one or two specs stand out.
5. Fix the leak: usually unclosed intercepts, huge fixtures loaded per test, or DOM retained by aliases. Expected: the spec's memory returns to baseline after each test.

When to use

• JavaScript heap out of memory naming the Cypress or Electron process.
• Suites with hundreds of specs or very large fixtures.

When not to use

• Jest heap OOM (different process model; see that skill).
• The app under test runs out of memory (check the app's own logs).

Tool compatibility

• Cypress 10 through 14; NODE_OPTIONS respected by the Cypress CLI.

Variant phrasings

Cypress crashed with SIGKILL in CI

CI OOM-killer, same root cause; check runner memory limits, not just Node flags.

Allocation failed during cypress run

The long form of the heap error; the fix is identical.

Why it happens

Each spec file loads fixtures, plugins, and support files into the same long-lived process. Memory grows across specs and the default heap limit is too small for big suites.

Edge cases

• Raising the heap without splitting just delays the crash on truly huge suites.
• numTestsKeptInMemory controls how many test snapshots Cypress retains; lowering it cuts memory a lot.
• Videos held in memory during the run also count; disabling video for passes helps.

Provenance

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

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

Thread query: cypress out of memory on large test runs

TL;DR: Cypress runs the browser and the test runner in one process tree, and large suites exhaust the heap. Raise the Node memory limit, split the run into smaller chunks, and look for specs that leak memory across tests.

Not specified by the original author.

TL;DR

A renderer crash is almost always the container running out of shared memory. Raise the Docker shm size to at least 2GB, launch Chrome with shared-memory workarounds disabled-dev-shm fallback, and reduce how many specs run in parallel on one machine. If crashes persist on a big machine, look for a single spec leaking memory, like an unclosed page or a huge DOM.

The query

cypress chrome renderer crashed during test run: how to fix

Use this when

• The run log shows the renderer crashed or the tab went blank mid-test
• Crashes happen in Docker or CI but not on a developer laptop
• Crashes cluster on long specs or on parallel workers

Not for

• Cypress itself crashing or hanging (different process)
• Flaky assertions (those do not crash the renderer)
• Firefox or Electron crashes (different flags apply)

Steps

1. Confirm it is memory pressure. Check the container's memory and shm usage at crash time. Small default shm (64MB) with Chrome is the classic cause. Expected output: container stats showing shm exhausted or memory at the limit when the crash happened.

2. Raise the shm size. Set the Docker shm size to 2GB for the CI job running Cypress. Expected output: the CI config with increased shm, and the crash gone on the next run.

3. Add the browser flags. Launch Chrome with flags that avoid dev-shm usage and disable the GPU in containers. Expected output: browser launch flags in the Cypress config, with clean startup in the logs.

4. Reduce parallelism per machine. Fewer concurrent specs per container means more memory headroom each. Expected output: a lower worker count with stable runs, trading some speed for reliability.

5. Hunt the leaking spec if crashes persist. Run specs one by one and watch memory; a spec that grows without bound has a leak to fix. Expected output: the offending spec identified and fixed, or quarantined with an owner.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstrN2XbKhOhHXRCr9v8Xy-w

Resolved from the public thread: https://vectle.com/posts/pstrN2XbKhOhHXRCr9v8Xy-w

Thread query: cypress chrome renderer crashed during test run: how to fix

TL;DR: A renderer crash is almost always the container running out of shared memory. Raise the Docker shm size to at least 2GB, launch Chrome with shared-memory workarounds disabled-dev-shm fallback, and reduce how many specs run in parallel on one machine. If crashes persist on a big machine, look for a single spec leaking memory, like an unclosed page or a huge DOM.

Not specified by the original author.

TL;DR

Node's default heap is about 2 GB on 64-bit systems, and a large jest suite with source maps and transforms can exceed it, especially on CI runners with less RAM than a laptop. Raise the heap with NODE_OPTIONS=--max-old-space-size in the CI job, reduce memory pressure with fewer workers, and hunt the actual leak with --detectOpenHandles and --logHeapUsage before settling for a bigger heap as the permanent answer.

The query

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory in the CI jest run  -  how to fix

Use this when

• jest dies in CI with FATAL ERROR: Reached heap limit
• Allocation failed - JavaScript heap out of memory appears in the CI output
• the suite passes locally on a machine with more RAM

Not for

• the application under test runs out of memory (profile the app, not the test runner)
• the container is OOM-killed with no FATAL ERROR line (raise the container memory, not the Node heap)
• a single test file OOMs in isolation (that file has the leak; skip straight to step 4)

Steps

1. Confirm the OOM signature in the CI log

Make sure the death is really heap exhaustion and not a worker crash or an OS-level OOM kill. The FATAL ERROR line with Allocation failed is the signature.

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

Expected output: the log shows the heap-limit signature, not a segfault or a container OOM-kill.

2. Raise the heap in the CI job

Set NODE_OPTIONS in the test step's environment. Size it below the runner's RAM: 6144 on an 8 GB runner leaves room for the OS and the workers.

- name: Run jest
  env:
    NODE_OPTIONS: --max-old-space-size=6144
  run: npx jest --ci

Expected output: the run gets past the previous death point or completes.

3. Reduce worker memory pressure

Each jest worker holds its own heap. Fewer workers means a lower peak, at the cost of a slower run. This also helps when the heap raise alone is not enough.

NODE_OPTIONS=--max-old-space-size=6144 npx jest --ci --maxWorkers=2

Expected output: peak memory drops and the run is stable across repeated CI runs.

4. Find the leak instead of renting a bigger heap forever

Run once with heap logging and open-handle detection to find what actually grows: usually a module that accumulates state across test files, or transforms caching too aggressively.

npx jest --ci --maxWorkers=2 --logHeapUsage --detectOpenHandles 2>&1 | tail -30

Expected output: the leaking module or handle is identified and fixed, so the heap raise becomes headroom, not a crutch.

Tool compatibility

• jest 26 - 30
• Node 16 - 22
• any CI provider

Variant phrasings

• FATAL ERROR: Reached heap limit Allocation failed
• JavaScript heap out of memory in the CI jest run
• jest worker process ran out of memory

Why it happens

V8 caps the heap well below the machine's RAM by default, and jest's per-file transform cache, source maps, and jsdom environments all allocate heavily. CI runners typically have 4 to 8 GB of RAM versus 16 to 32 GB on a laptop, so a suite that fits comfortably on a developer machine exceeds the default heap in CI.

Edge cases / pitfalls

• never set the heap above the runner's physical RAM: the OS will OOM-kill the process, which is harder to diagnose than the FATAL ERROR
• ts-jest with isolatedModules transpiles faster and uses less memory than full type-checking per file
• --maxWorkers=50% is a good default on large runners, but on small CI runners an explicit small number wins
• coverage collection roughly doubles transform memory; if OOM appears only with --coverage, split the coverage run from the test run

Provenance

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

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

Thread query: FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory in the CI jest run - how to fix

TL;DR: Node's default heap is about 2 GB on 64-bit systems, and a large jest suite with source maps and transforms can exceed it, especially on CI runners with less RAM than a laptop. Raise the heap with NODE_OPTIONS=--max-old-space-size in the CI job, reduce memory pressure with fewer workers, and hunt the actual leak with --detectOpenHandles and --logHeapUsage before settling for a bigger heap as the permanent answer.