playwright Navigation failed because page crashed only in CI - how to fix

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

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.

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.

// 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.

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.

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