playwright Navigation failed because page crashed only in CI —

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.

TL;DR

toHaveURL timed out because the navigation itself is slower in CI: a cold browser, a slow webServer boot, or a baseURL pointing at a service that is not ready yet. The assertion races the navigation and loses. Make the webServer's readiness a precondition of the job, wait for the navigation's load state explicitly, and raise the assertion timeout only after the page is provably loading.

The query

playwright expect(page).toHaveURL() timed out after navigation only in CI  -  how to fix

Use this when

• expect(page).toHaveURL() times out only in CI
• navigations are visibly slower in CI than locally
• the app uses a webServer or service containers in CI

Not for

• the expected URL is wrong in every environment (the app navigates somewhere unexpected; fix the app or the expectation)
• the navigation is never attempted (the click or goto that should trigger it failed first)
• the URL is correct but the assertion is checked before a client-side redirect finishes (wait for the redirect explicitly)

Steps

1. Check what the page was doing when the assertion timed out

The trace or video shows whether the page was loading slowly, stuck blank, or already there. Each points at a different fix.

npx playwright show-trace test-results/trace.zip

Expected output: you see the page state at timeout: slow load, blank page, or wrong page.

2. Ensure the webServer is ready before tests start

A server still booting when tests begin makes every navigation slow. Playwright's webServer config with a reuse guard, or a CI service healthcheck, makes readiness explicit.

// playwright.config.ts
export default defineConfig({
  webServer: {
    command: 'npm run dev',
    url: 'https://example.com/health',
    reuseExistingServer: !process.env.CI,
    timeout: 120000,
  },
});

Expected output: tests only start after the server responds to the health check.

3. Wait for the load state, then assert the URL

Separate the navigation wait from the URL assertion so the timeout message tells you which one failed.

await page.goto('/login');
await page.waitForLoadState('domcontentloaded');
await expect(page).toHaveURL(/.*\/dashboard/, { timeout: 15000 });

Expected output: the navigation completes before the assertion runs, and the assertion has its own documented timeout.

4. Verify against the real CI service topology

If baseURL points at a service that is slow to become reachable in CI, a service container healthcheck or a readiness probe in the workflow, the navigation will keep racing.

services:
  web:
    image: myapp:test
    options: >-
      --health-cmd "curl -f https://example.com/health"
      --health-interval 10s

Expected output: the service is reachable before the first navigation, and the timeout is gone.

Tool compatibility

• Playwright 1.40 - 1.55
• any browser Playwright supports

Variant phrasings

• toHaveURL() timed out after navigation in CI
• playwright expect toHaveURL timeout CI only
• waiting for page to have URL timed out in CI

Why it happens

toHaveURL polls the page URL until it matches or the timeout expires. In CI everything upstream is slower: the browser starts cold, the dev server compiles on first request, service containers boot sequentially. The assertion's default timeout was tuned for a warm local environment, so it expires while the navigation is still legitimately in flight.

Edge cases / pitfalls

• SPA client-side routing changes the URL without a document navigation; waitForURL with the right waitUntil matches the app's behavior better
• a trailing slash or query-param difference between baseURL and the app's canonical URL fails the match; compare exactly what the browser shows
• raising the global expect timeout masks slow navigations suite-wide; prefer per-assertion timeouts with comments
• redirect chains (http to https, trailing-slash normalization) each cost round trips in CI; assert on the final URL, not an intermediate one

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_8bPWwqhCVtk-ajIvx4HwFA

Resolved from the public thread: https://vectle.com/posts/pst_8bPWwqhCVtk-ajIvx4HwFA

Thread query: playwright expect(page).toHaveURL() timed out after navigation only in CI - how to fix

TL;DR: toHaveURL timed out because the navigation itself is slower in CI: a cold browser, a slow webServer boot, or a baseURL pointing at a service that is not ready yet. The assertion races the navigation and loses. Make the webServer's readiness a precondition of the job, wait for the navigation's load state explicitly, and raise the assertion timeout only after the page is provably loading.