## TL;DR
The Chromium renderer crashed mid-navigation, and in CI that is almost always memory pressure: docker containers default /dev/shm to 64 MB while Chromium wants far more for rendering. Pass --disable-dev-shm-usage so Chromium uses /tmp instead, lower parallel workers to reduce contention, and check whether the page itself leaks memory before asking for a bigger container.

## The query
```text
playwright Navigation failed because page crashed only in CI  -  how to fix
```

## Use this when
- Navigation failed because page crashed appears only in CI
- the CI job runs in docker or another container
- the same navigation is stable on developer machines

## Not for
- the page crashes in every environment (that is an app bug; fix the page)
- the error is browser has been closed (the whole browser died, not just the page)
- navigation times out without a crash (that is slowness, not a crash)

## Steps

### 1. Confirm the crash signature in the CI output
Make sure this is a renderer crash and not a navigation bug: the error says the page crashed, and the trace or log mentions the target crashing.
```text
Navigation failed because page crashed
```
Expected output: the error names a crashed page rather than a timeout, a refused connection, or a bad URL.

### 2. Pass --disable-dev-shm-usage to Chromium
This is the standard fix for docker-based CI. It makes Chromium back shared memory with /tmp instead of the tiny /dev/shm.
```ts
// playwright.config.ts
import { defineConfig } from '@playwright/test';
export default defineConfig({
  use: {
    launchOptions: { args: ['--disable-dev-shm-usage'] },
  },
});
```
Expected output: navigations that crashed now complete in the same container.

### 3. Lower worker parallelism
Fewer concurrent pages means less memory contention. This is a tradeoff with run duration, so measure both.
```bash
npx playwright test --workers=2
```
Expected output: peak memory drops and the crash stops recurring across repeated runs.

### 4. Check the page's own memory footprint
If the crash persists, the page itself may be the problem: huge DOMs, unthrottled canvases, or leaked event listeners. Profile locally with the same launch args.
```js
const usage = await page.evaluate(() => performance.memory.usedJSHeapSize);
console.log('heap bytes:', usage);
```
Expected output: you know whether the app page is heavy (fix the page) or light (the container was the problem).

## Tool compatibility
- Playwright 1.40 - 1.55
- Chromium in docker-based CI

## Variant phrasings
- Navigation failed because page crashed only in CI
- playwright Target crashed during navigation in docker
- page crashed error in CI but not locally playwright

## Why it happens
Chromium uses /dev/shm for shared memory between its processes, and docker defaults that filesystem to 64 MB. Rendering a modern page needs hundreds of megabytes, so the renderer dies mid-navigation. Developer machines are not containers, so they never hit the limit, which is why the crash is CI-only.

## Edge cases / pitfalls
- --disable-dev-shm-usage slightly changes rendering performance characteristics; keep it in local runs too so environments match
- headless shell versus full Chromium have different memory profiles; test with the same channel CI uses
- video recording and tracing raise memory further; a crash that starts when you enable tracing is still the same root cause
- raising the container's shm-size is the alternative fix when you control the docker flags

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-aTvzqjNqZ4KbTQdQEpY8w