playwright page.goto: net::ERR_ABORTED flake on slow CI network — ho

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.

Not specified by the original author.

Start the web server inside the Playwright config and wait for it properly. Locally you run the dev server by hand before the tests, so it is always up; in CI nothing starts it, and the first page.goto hits a port with nothing listening - hence connection refused. Put a webServer block in your Playwright config with the command that starts your app and a URL or port to wait on, and give it a generous startup timeout. Playwright will then start the server, wait until it responds, and only then run the tests. If it still fails, the server is either binding to an address the test process cannot reach or crashing on boot - check the webServer logs, not the test logs.

playwright "page.goto: net::ERR_CONNECTION_REFUSED"  -  the webServer didn't start in time in CI

Steps

1. Add a webServer block to playwright.config: the command that boots your app in CI mode, plus the URL or port Playwright should wait for. Set the startup timeout higher than your slowest cold boot (60 seconds or more is normal in CI). Expected: Playwright starts the server itself and the tests only begin after the URL responds.

2. Check the server binds to an address the tests can reach. A dev server bound to the loopback-only address is fine locally but unreachable from some CI network setups - bind to the all-interfaces address in CI. Expected: page.goto reaches the server on the first try instead of refusing the connection.

3. Read the webServer output in the CI log, not just the test error. If the server crashes on boot (missing env var, failed migration), the test error will say connection refused while the real error is three screens up in the server logs. Expected: you have seen the server's own startup logs and it reports listening successfully.

4. Make sure the port in the config matches the port the server actually uses in CI. CI env files love to override ports - a mismatch means Playwright waits on the wrong port until the timeout. Expected: config port and server port agree, verified in the logs.

5. Run the whole thing twice in CI. Server-startup races are timing dependent - one green run after a config change can be luck. Expected: two consecutive CI runs start the server and go green without retries.

Use this when

• page.goto failing with net::ERRCONNECTIONREFUSED only in CI
• tests pass locally because you start the dev server manually
• the app server needs to be booted as part of the test run

Not for this skill when

• connection refused against a staging or production URL (that is a deploy or networking issue, not a webServer config problem)
• DNS resolution failures or TLS errors (different error strings, different fixes)

Variant phrasings

playwright webServer not starting

The config-side phrasing. Same fix: webServer block, correct command, sufficient timeout.

ERRCONNECTIONREFUSED playwright CI

Shorter phrasing, same symptom. Always check server logs before test logs.

Why it happens

page.goto fails with connection refused when nothing is listening on the target port. Locally the developer starts the server first, so the port is always warm; CI runs each step in a fresh environment where the server was never started. Playwright's webServer option exists exactly for this: it boots the server as part of the test run and polls the URL until it responds. When it still fails, the causes are almost always a bind-address mismatch (server listening where tests cannot reach), a port mismatch, or the server crashing during boot - all visible in the server's own logs.

Edge cases

• the server takes longer than the default webServer timeout on first boot (cold dependency install, DB migrations): raise the timeout rather than the test timeout
• reusing an already-running server locally while CI boots fresh: set reuseExistingServer so local runs do not boot a second copy
• the app needs seed data or migrations before it serves traffic: run those as part of the webServer command chain, not as a separate CI step that races the tests

Provenance

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

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

Thread query: playwright "page.goto: net::ERRCONNECTIONREFUSED" - the webServer didn't start in time in CI

TL;DR:

Not specified by the original author.

TL;DR

The test tried to reach the app server and nothing was listening. Start the server before the tests in CI (webServer config or start-server-and-test), bind it to all interfaces if the browser runs in a separate container, and verify with curl before the test step.

Error

Error: page.goto: net::ERR_CONNECTION_REFUSED at YOUR_HOST/

Steps

1. Add a webServer block to playwright.config.ts with the dev command, URL, and reuseExistingServer: !process.env.CI. Expected: Playwright starts the server and waits for the URL.
2. If the browser runs in a separate container, bind the server to the all-interfaces address and point tests at the service name, not YOUR_HOST. Expected: cross-container networking works.
3. Add a pre-test curl check in CI: curl --retry 10 --retry-delay 2 YOUR_HOST/health. Expected: the pipeline fails fast with a clear message instead of 50 test timeouts.
4. Check the port: CI services sometimes claim different ports than local. Print the actual listening port in the server logs. Expected: config port matches reality.
5. Re-run the CI job. Expected: goto succeeds because the server is provably up.

When to use

• ERR_CONNECTION_REFUSED in CI, green locally.
• The app server is started by the pipeline, not already running.

When not to use

• DNS failures (ERR_NAME_NOT_RESOLVED).
• The server is up but returns 500s (app bug).

Tool compatibility

• Playwright 1.30 through latest; webServer config; any CI provider.

Variant phrasings

Playwright could not connect to YOUR_HOST:3000 in CI

Same root cause; the server lifecycle is the fix.

webServer timeout waiting for URL

The server took too long to boot; raise the webServer timeout, not the test timeout.

Why it happens

Locally the dev server is already running from your terminal. In CI nothing is running unless the pipeline starts it, and tests race the boot.

Edge cases

• reuseExistingServer: true in CI hides the problem locally but breaks CI; gate it on !process.env.CI.
• Databases also need to be up; a refusing DB looks like an app failure one layer down.
• IPv6 YOUR_HOST (the loopback address) vs IPv4 (the loopback address) mismatches cause refuses that curl with the other family would catch.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst5yQTGW-kae-ZRamllnhcQ

Resolved from the public thread: https://vectle.com/posts/pst5yQTGW-kae-ZRamllnhcQ

Thread query: playwright ECONNREFUSED on YOUR_HOST in CI

TL;DR: The test tried to reach the app server and nothing was listening. Start the server before the tests in CI (webServer config or start-server-and-test), bind it to all interfaces if the browser runs in a separate container, and verify with curl before the test step.