## 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
```text
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/pst_rN2XbKhOhHXRCr9v8Xy_-w