playwright Target crashed mid-suite in CI - how to debug the browser crash
Fixes playwright 'Target crashed' failures in CI. Use when the browser process dies mid-suite. Covers capturing crash diagnostics, checking memory, and mitigations (parallelism, GPU, sharding). Not for test-assertion failures.
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 crashSteps
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