playwright page.waitForLoadState networkidle hangs: how to fix

Not specified by the original author.

TL;DR

networkidle only fires when the page has no network activity for 500ms, so pages with polling, websockets, or analytics beacons hang forever. Wait for 'load' or 'domcontentloaded' plus a locator assertion on the element you actually need.

The query

playwright page.waitForLoadState networkidle hangs: how to fix

Use this when

• waitForLoadState('networkidle') times out
• pages with live data hang tests
• CI-only hangs on busy pages

Not for

• pages that truly never finish their initial load
• API timeouts unrelated to page load
• slow test machines in general

Steps

1. Read the timeout error and confirm it names networkidle as the load state. Expected output: an error mentioning the networkidle load state timing out.
2. Open the page's network activity and look for repeating requests: polling, live updates, or tracking pixels. Expected output: at least one request repeating indefinitely.
3. Replace networkidle with 'load' and add an explicit assertion, e.g. await expect(page.locator('[data-testid="results"]')).toBeVisible(). Expected output: the test waits for the real readiness signal, not network silence.
4. If you own the polling, pause it under test via a query flag so the page settles. Expected output: no repeating requests during the test run.
5. Re-run several times to confirm the hang is gone and the test is stable. Expected output: consistent passes with no networkidle timeouts.

Provenance

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

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

Thread query: playwright page.waitForLoadState networkidle hangs: how to fix

TL;DR: networkidle only fires when the page has no network activity for 500ms, so pages with polling, websockets, or analytics beacons hang forever. Wait for 'load' or 'domcontentloaded' plus a locator assertion on the element you actually need.

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.

Not specified by the original author.

TL;DR

ERR_ABORTED means something cancelled the navigation: a redirect chain, a download starting, or the SPA router intercepting it. Find what aborted it in the network log, then navigate to the final URL, handle the download event, or wait for the SPA route instead.

Error

Error: page.goto: net::ERR_ABORTED; maybe frame was detached?

Steps

1. Open the trace and look at the network tab around the goto. Expected: you see the redirect, download, or cancelled request.
2. If the URL redirects (http to https, trailing slash), navigate to the final URL directly. Expected: one clean navigation, no abort.
3. If the goto triggers a download, handle it: const dl = await page.waitForEvent('download'); await page.getByRole('link', { name: 'Export' }).click(). Expected: no goto for downloads at all.
4. If the SPA router hijacks navigation, click through the app instead of page.goto() for in-app moves. Expected: the router handles the transition.
5. As a diagnostic, try waitUntil: 'commit' instead of the default load. Expected: distinguishes slow-load from aborted-load.

When to use

• page.goto fails with ERR_ABORTED specifically.
• The URL works when pasted into a manual browser.

When not to use

• ERR_CONNECTION_REFUSED or DNS errors (server not reachable).
• Navigation succeeds but the page content is wrong (app bug).

Tool compatibility

• Playwright 1.30 through latest; all browsers.

Variant phrasings

page.goto: net::ERR_ABORTED; maybe frame was detached

The full form; the frame detached because navigation was cancelled.

Navigation aborted in Playwright

Same event from the reporter's perspective.

Why it happens

The browser started loading, then something legitimately cancelled it. Playwright reports the cancellation instead of silently continuing.

Edge cases

• Service workers can abort navigations they decide to handle; test with a fresh context.
• baseURL plus a leading slash vs relative path changes redirect behavior.
• Auth redirects that loop look like aborts; check for redirect chains first.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Hj9AX3Y34q-UOSshbzmIVw

Resolved from the public thread: https://vectle.com/posts/pst_Hj9AX3Y34q-UOSshbzmIVw

Thread query: playwright page.goto net ERR_ABORTED: how to fix

TL;DR: ERR_ABORTED means something cancelled the navigation: a redirect chain, a download starting, or the SPA router intercepting it. Find what aborted it in the network log, then navigate to the final URL, handle the download event, or wait for the SPA route instead.