Playwright "Target page, context or browser has been closed": causes and fixes

What the error means

Playwright raises this error when an operation needs a page, browser context or browser that no longer exists. It is prefixed with the call that was waiting, so you see it in forms like these:

locator.click: Target page, context or browser has been closed
page.goto: Target page, context or browser has been closed
browser.newContext: Target page, context or browser has been closed

The method name tells you what was waiting, not what closed it. Something else closed the target first: the test finishing, a timeout, your own close() call, or a crash. Each has a different fix.

Cause 1: a missing await

Playwright calls are asynchronous. Without await, the test function can return while the call is still running. Playwright then tears down the test, closes the page and its context, and the forgotten call fails with this error, sometimes in a later test's output:

test('saves the form', async ({ page }) => {
  await page.goto('/settings');
  page.getByRole('button', { name: 'Save' }).click(); // missing await
});

Add the await. To catch every case, Playwright's best practices recommend the @typescript-eslint/no-floating-promises ESLint rule, which flags calls whose promise is not awaited, and running tsc --noEmit in CI. Watch for the same bug in helpers: a function that calls Playwright must be async, and its callers must await it.

Event handlers are a variant of this. An async handler on page.on('response') that does more Playwright work can still be running after the test ends. Keep handlers synchronous, or collect what you need and await it inside the test.

Cause 2: the test timed out

When a test hits its timeout (30 seconds by default), Playwright stops it and closes its page and context. An action that was still waiting, for example a click on an element that never became enabled, then fails with this error. In the output it appears together with Test timeout of 30000ms exceeded.

The real problem is the timeout. Open the trace and look at what the last action was waiting for. Raise the timeout only if the test is genuinely slow (test.slow() triples it for one test); otherwise fix the wait.

Cause 3: the page or browser was closed by your code

Calling page.close(), context.close() or browser.close() while something still uses it gives the same error. Typical places:

• An afterEach or afterAll that closes a page that the test (or a forgotten promise) is still using.
• A test that clicks a link which closes the window or tab, then keeps using the old page.
• A page stored in a variable from one test and used in another. Playwright gives every test its own page; the old one is closed when its test ends.

If tests really must share a page, create it yourself in beforeAll and close it in afterAll, as Playwright's retries guide shows, and run those tests serially.

Cause 4: the browser crashed

If the browser process crashes, every page and context in it is gone, and the next call fails with this error. In CI the usual reason is memory. Playwright's Docker guide says that without --ipc=host, Chromium can run out of memory and crash. Lowering workers in CI is a quick way to test the memory theory: if the error disappears with fewer workers, it was memory.

Look for other clues in the same run: Target crashed, Page crashed, or `worker process exited unexpectedly` mean the process died rather than your code closing it.

Cause 5: launching the browser failed

When the message comes from browserType.launch or browser.newContext, the browser may have closed while starting. Read the browser log Playwright prints under the error: missing system libraries, a sandbox problem in a container, or a browser version that does not match the installed Playwright. npx playwright install --with-deps installs the browsers and the system dependencies for the version you have.

A quick checklist

1. Read the method in the prefix and the message just before it (timeout, crash, launch log).
2. Turn on @typescript-eslint/no-floating-promises and fix every finding.
3. If it comes with a test timeout, debug the timeout with the trace.
4. Search for close() calls and page variables shared between tests.
5. In CI, try fewer workers and --ipc=host in Docker to rule out memory.

Is it new, or has it been happening for weeks?

This error is often intermittent: a missing await only fails when the timing is unlucky, and a memory crash only when the machine is busy. That makes it look like a flaky test. Knowing whether a failure is new on your branch, already happening on main, or a known flaky test saves a lot of guessing.

TurnSignal keeps each test's results across runs and branches. Every failure on a pull request is labelled new, also failing on main or known flaky, failures caused by a browser or worker crash are labelled as crashes, and the trace opens in the browser from the run page. The reporter never changes your exit code; setup is in the docs.