playwright Navigation failed because page crashed only in CI — how to

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

'Target crashed' means the browser process died, usually from memory pressure or GPU issues in CI. Capture diagnostics (crash dumps, CI memory stats), reduce parallel workers, disable GPU (--disable-gpu), and shard the suite. Debug the crash as infrastructure first, the tests second.

The symptom

playwright Target crashed mid-suite in CI  -  how to debug the browser crash

Steps

1. Capture crash diagnostics

Enable crash reporting and collect the CI job's memory stats around the crash. Note which test was running. Expected: Crash context: memory pressure visible or not.

2. Check memory pressure

Compare the browser's memory use against the container/VM limit. Target crashes under OOM are the most common cause. Expected: Memory verdict: pressured or not.

3. Mitigate: workers, GPU, sharding

Reduce playwright workers, launch with --disable-gpu, and shard the suite so each browser does less. Expected: Crash stops reproducing under lighter load.

4. Rerun the full suite

Run the suite with the mitigations in place across several runs. Expected: Stable green across runs.

When to use

• playwright 'Target crashed' or 'Target closed' mid-suite
• Browser dies without a test assertion failing
• CI runners are small or heavily parallel

When not to use

• Tests fail with assertions (not crashes)
• The crash reproduces on a big machine (then it may be the page itself)
• Only one specific page crashes (debug that page's content)

Why it happens

CI runners are smaller than dev machines, and browsers are memory-hungry. Under parallel workers the browser exhausts memory and the OS kills it; playwright reports 'Target crashed'. It looks like a test failure but it is the browser dying underneath the tests.

Edge cases

• A single page that always crashes the browser: likely the page (huge DOM, WebGL); still start with memory.
• Chromium vs Firefox vs WebKit: crash behavior differs; note the browser.
• Retries on crash: use with care; they hide the pressure signal.

Provenance

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

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

Thread query: playwright Target crashed mid-suite in CI - how to debug the browser crash

TL;DR: 'Target crashed' means the browser process died, usually from memory pressure or GPU issues in CI. Capture diagnostics (crash dumps, CI memory stats), reduce parallel workers, disable GPU (--disable-gpu), and shard the suite. Debug the crash as infrastructure first, the tests second.

Not specified by the original author.

Find out what killed the browser process. "Browser has been closed" mid-suite almost never means your test closed it - it means something outside the test did: the container ran out of memory and the OOM killer shot the browser, a fixture tore down a shared browser while other tests still needed it, or too many parallel workers starved the machine. Check CI memory metrics and dmesg-style logs first; if the browser died from memory pressure, cut workers or raise the container limit. If the timing lines up with a fixture teardown, the sharing is wrong. Guessing between these wastes hours - the logs tell you which one it is.

playwright "browser has been closed" error mid-suite in CI: what causes it

Steps

1. Look at when the error hits: same test every run (fixture or code problem) or random tests at random times (resource problem). Randomness points at memory. Expected: you have classified the failure as deterministic or random.

2. Check CI memory: look at the container memory limit and peak usage in the CI logs. If the browser dies near the limit, the OOM killer is your culprit - add the flag that moves shared memory off the small default partition, or lower the worker count. Expected: memory pressure is confirmed or ruled out with numbers, not guesses.

3. Audit browser lifecycle: search fixtures and hooks for any close call on a shared browser or context. A fixture that closes the shared browser in teardown while another worker still uses it produces exactly this error. Expected: every close call is accounted for and shared browsers are closed exactly once, at the very end.

4. Reduce parallelism as a diagnostic: run CI with one worker. If the error disappears, you have resource contention - then decide between fewer workers permanently or a bigger CI machine. Expected: a single-worker run is green, proving contention rather than code.

5. Make the fix structural: set a sensible worker count for the CI machine size, keep browser launch args that survive small containers, and never share-then-close a browser across workers. Expected: the suite passes at full parallelism three runs in a row.

Use this when

• "browser has been closed" appearing mid-suite in CI while local runs are fine
• random tests dying at random points in CI
• you need to separate OOM kills from fixture teardown bugs

Not for this skill when

• the error at suite start before any test runs (that is a launch problem - browsers not installed or sandbox flags)
• your own test code explicitly closing the browser (that is visible in the test - just do not close it early)

Variant phrasings

playwright browser closed unexpectedly

Same symptom family. Mid-suite points to resources or teardown; at-start points to installation or launch flags.

playwright target closed

The older wording of the same event - the browser process went away while tests still needed it.

Why it happens

The browser is a separate OS process from the test runner. In CI it runs inside a container with hard memory limits, and browsers are hungry: each worker launches full browser processes with renderers and GPU processes. When the container hits its limit, the kernel OOM killer picks the biggest process - usually the browser - and the test runner only learns about it when its next command fails with "browser has been closed". Separately, Playwright fixtures that share one browser across tests will produce the same error if any teardown closes it early.

Edge cases

• the error only on one CI provider: compare container memory defaults - some providers give much less memory per runner than others
• headed versus headless: headed browsers need a display server and more memory; CI should run headless unless the test needs headed
• video and trace recording on every test: these inflate memory and disk - record on failure only in CI

Provenance

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

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

Thread query: playwright "browser has been closed" error mid-suite in CI: what causes it

TL;DR: