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

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:

Not specified by the original author.

TL;DR

Playwright throws this when your code touches a page, context, or browser after it was closed. The usual shape is an awaited action racing a close in a fixture, or the whole browser crashing (often out of memory or missing system libraries in CI). Fix the ordering first; if the browser itself died, the launch logs tell you why.

Error

Error: Target page, context or browser has been closed

Steps

1. Find the close: search the test for browser.close(), context.close(), page.close(), and any fixture teardown that runs before the failing line. Expected: you spot the action that runs after a close.
2. Await in order: make sure closes are awaited and happen after the last action, e.g. close in afterEach or afterAll, not mid-test. Expected: no action runs on a closed target.
3. If nothing in your code closes it, the browser crashed: re-run with DEBUG=pw:browser to see the crash output. Expected: the logs show either a clean close or a crash reason.
4. In CI, install system dependencies: npx playwright install --with-deps chromium. Expected: missing shared libraries stop killing the browser at launch.
5. Reduce crash odds in containers: launch with args: ['--disable-dev-shm-usage'] or give the container more memory. Expected: renderer out-of-memory crashes disappear.

When to use

• The error appears right after a navigation or click.
• It happens only in CI or Docker, never locally.
• It started after adding a fixture that closes pages or contexts.

When not to use

• Timeout 30000ms exceeded waiting for a selector (a selector or timing issue).
• The error appears at the very start before anything runs (launch failed; check the install).
• The browser window visibly crashes with an OS dialog (read the dialog, not this skill).

Tool compatibility

• Playwright 1.30 and newer, Chromium, Firefox, and WebKit.
• Node.js, Python, Java, and .NET bindings.

Variant phrasings

Target closed

The short form of the same error; same diagnosis.

happens on page.screenshot after the test ends

Teardown ordering: the screenshot runs after the fixture closed the page. Move it before the close.

intermittent in parallel runs

Resource exhaustion under parallelism. Fewer workers or more memory.

Why it happens

Every Playwright action goes through the browser process; once the target closes (your code closed it, the test ended, or the process crashed), the pending protocol call has nowhere to go. In CI the crash is usually missing OS libraries or shared-memory exhaustion killing Chromium.

Edge cases

• DEBUG=pw:browser output is the fastest crash diagnosis; read it before changing code.
• Closing the context closes its pages, so the safe order is pages first, then context, then browser.
• Slowing the test down does not help a crash; it only helps a timeout.

Provenance

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

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

Thread query: playwright target page, context or browser has been closed

TL;DR: Playwright throws this when your code touches a page, context, or browser after it was closed. The usual shape is an awaited action racing a close in a fixture, or the whole browser crashing (often out of memory or missing system libraries in CI). Fix the ordering first; if the browser itself died, the launch logs tell you why.

Not specified by the original author.

TL;DR

The browser process itself died: crashed, OOM-killed, or closed by a fixture. Check crash logs and memory, isolate the crashing test, and stop sharing browser instances across tests that kill them.

Error

Error: browser has been closed

Steps

1. Run the failing test alone: npx playwright test path/to.spec.ts. Expected: if it passes alone, another test in the file kills the browser.
2. Check CI memory: browser crashes under memory pressure look exactly like this. Add memory to the runner or reduce workers. Expected: crashes stop when memory is sufficient.
3. Look for browser.close() in fixtures or helpers that run while other tests still use the browser. Expected: you find the premature close.
4. Enable crash reporting: run with --reporter=list and check for Crashpad or segfault lines in output. Expected: confirms crash vs close.
5. Bisect: run half the file, then half again, until one test reproduces the crash. Expected: a single crashing test to fix or quarantine.

When to use

• The error names the browser, not a page or locator.
• Multiple tests fail at once when one crashes.

When not to use

• Target closed (page-level, not browser-level).
• Launch failures before any test runs (browser install issue).

Tool compatibility

• Playwright 1.30 through latest; Chromium, Firefox, WebKit.

Variant phrasings

Playwright browser disconnected

The driver lost the browser pipe; same family of causes.

Browser crashed during Playwright run

Usually OOM; check runner memory first.

Why it happens

One browser serves many tests. A crash or close kills everything attached to it, so one bad test poisons the whole file.

Edge cases

• WebKit is the most crash-prone under memory pressure; give it more headroom or fewer workers.
• Video recording increases memory; disable it while bisecting crashes.
• --workers=1 hides cross-test interference; the crash may still be a real per-test bug.

Provenance

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

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

Thread query: playwright browser has been closed mid-test: how to fix

TL;DR: The browser process itself died: crashed, OOM-killed, or closed by a fixture. Check crash logs and memory, isolate the crashing test, and stop sharing browser instances across tests that kill them.