playwright: [BUG] page.goto: Timeout XXXms exceeded. No load or domcontentloaded event fired

Ok, but how to solve it?

Facing similar issue.

Intermittently tests fail only in pipeline while calling page.goto

Using Playwright version 1.31.0.

How to resolve this?

Just to chime in a little bit on adding some insights, why your tests might fail on CI and seem to be flaky (or blaming Playwright for that matter) - for us, we are using pure ESM modules and if all of your dependencies are native ESM and are optimized for tree-shaking (meaning every tiny function is exposed as ESM module), if you do not bundle anything at all, this easily amounts to crazy amounts of requests being made:

• using @popperjs/core/lib/popper-lite.js roughly amounts to 40+ requests (while only tallying ~70kB)
• using even such simple things like lodash-es/isEqual.js amounts to another 30+ requests

In our scenario, where we “just” user 5 components from our UI library, this amounts to +150 requests. Browsers limit the amount of parallel HTTP requests and if HTTPS involved, this is not going to get any faster… So what I am saying is, that even my beefy (sorry veggies!) MacBook takes roughly a second for loading. We limited the Playwright timeouts to 4s and it seems, that hosted AzureDevOps Mac OS agents have pretty bad I/O performance, read by factor 5-10 slower, so this explains for us failed timeouts, because the load event is not triggered in time, because esm modules need to be “resolved” before actual DOM processing can happen.

We might think about using bundles for our tests; but for the time being, we solved this by having a platform-dependent global timeout set for Playwright.

Hello , we are also facing the same issue with timeouts happening randomly. We are running close to 60k tests across multiple machines in 20 minutes. This problem happens when tests run in a pipeline and not when they are running in local.

OS: windows playwright version : 1.13.0 Dot net version : 5 and 6

any help in this regard will be very useful @zhanglei4333 @liuxingbaoyu @tillschander .

Fixed in #13340

Similar to others, I’m seeing this issue on the latest (1.33.x) version. It’s only happening in CircleCi runs, but consistently fails during the page.goto step for Safari (webkit) browser, and inconsistently on Chrome. We have a timeout of 60s, so as to try and combat performance issues.

Also like others have seen, the screenshots show the page as loaded… so it’s just the load event that it fails find.

Again, no issues running locally.

Same issue in chromium with fresh playwright version 1.31.2 😦 Also, it’s a little bit flaky

same issue Error: page.waitForLoadState: Navigation failed because page was closed! =========================== logs =========================== “domcontentloaded” event fired “networkidle” event fired please give the solution , its working in local , getting this error in github actions.

Not a fix by any means but if anyone needs an emergency hacky workaround this might help:

try {
  await page.goto(url, {
    timeout: 5000,
  });
} catch {
  // sometimes goto times out, so try again
  console.log('page.goto timed out, trying again');
  await page.goto(url);
}

I have very little to add to this topic, but MAYBE (hopefully?) it will help to someone.

We faced very similar issues just right now, I was pretty clueless why we get such timeouts, when everything is working locally, but on our environment, we faced such a random timeouts as well. Sometime, it was working, sometime it was not. It was very weird.

Well, TLDR… Most of the providers (mainly cloud ones) have some kind of limiting rules for amount of queries. In such a situation, if playwright will hit this limit (lets say 100 queries per minute), usually the server (to avoid DDOS) serve you 403 or any other page. In such a situation, playwright will be stuck on goto(‘’) or any assertion, because that assertion won’t be truthy. For our particular use-case, the situation was as well, that playwright was not rendering anything because of our 403 page…

So keep on mind as well that such a server infrastructure / logic can (potentially) be the problem as well. Mainly if you do not face these problems locally.

Same issue with 1.32.3, out of 7 tests, 1 random one has always this problem.

I have the same problem with Chromium on Ubuntu. So it’s not just a Firefox only issue.

Every time i run my tests one or two of them might fail randomly with the same waiting until load error:

page.waitForNavigation: Navigation failed because page was closed!
=========================== logs ===========================
waiting for navigation until "load"
============================================================

page.goto: Navigation failed because page was closed!
=========================== logs ===========================
navigating to "http://localhost:3000/some/url", waiting until "load"
============================================================

The corresponding code is nothing fancy. Here are some examples:

await Promise.all([
    page.waitForNavigation({ url: 'login' }),
    page.goto('login')
]);

await page.goto('search');
await expect(page.locator('h1')).toContainText('Search');
await page.goto('product/123456');
await expect(page.locator('h1')).toContainText('Product Title');

Also is happening to me using GitlabCI - Tests were working last week and suddenly I am getting timeout with page.goto() Locally everything is working fine, I’ve upgrade and also downgrade the playwright version but issue still persists. I’ve enabled the debug mode and this is what I am getting:

navigating to ".......", waiting until "load" +2ms
  pw:api   "commit" event fired +1s
  pw:api   navigated to "..........." +0ms
  pw:api   "domcontentloaded" event fired +1s
  pw:api   navigated to "about:blank" +1s
  pw:api   navigated to "about:blank" +2ms
  pw:api   "commit" event fired +305ms
  pw:api   navigated to ".........." +0ms
  pw:api   "domcontentloaded" event fired +696ms
  pw:api   navigated to "about:blank" +1s
  pw:api   navigated to "about:blank" +34ms
  pw:api <= page.goto failed +2s

I can see in the video recording that the test was able to open the page (page is loading properly) but for some reason it’s firing timeout when test is being executed on CI. Also, I’ve tried placing the page.goto() in different places (beforeEach, test level, etc) and is throwing timeout always, checked the traces but everything looks good. This is becoming a blocker since we can not execute any test on CI - every single test is crashing because of the timeout, I tried by increasing it but not working either.

Any insights?

Also time to time see this issue in all browsers

Same issue

Similar issue when running on TeamCity agent. Playwright 1.31.1. Happens mostly in page.WaitForURLAsync() method after clicking Login button and redirecting to homepage (timeout exception: waiting for navigation to “***” until “Load”). Seems like redirecting mechanism somehow affects a current page. As a result, target page is loaded, but the WaitForURLAsync method fails…

We were experiencing the same problem, only in our CI pipelines (tests working locally, failing randomly in pipelines). The following in our playwright config has seemed to fix the problem for us:

// limit the number of workers running. start with 1, and if your tests pass reliably, consider increasing to
// speed up runs. the new % option may be a good choice, e.g.  workers: '50%'
workers: 1,

use: {
    // set this to a large number, to account for pages occasionally loading more slowly in your pipeline
    // than they do locally
    actionTimeout: 12000,

Based on the comments above and our experience, my thought is that the vm that’s running our tests in ci pipeline just gets a bit overwhelmed in terms of resources. Tons of workers spawning new tests, all running at once, and one just hangs up a bit because ram and cpu are scarce.

An additional source of this problem could be the fact locally, we’re running tests on localhost; in our pipeline, we’re running tests on a real staging website. Websites are fickle, and pages can sometimes load slowly. Increasing the actionTimeout may help with that.

If you’re still getting failures, you could consider allowing retries. In an ideal world, tests that should pass would pass 100% of the time. In the real world, even if you’re running your webapp within a container in your ci pipeline and testing against that (rather than running your tests against a real website), sometimes a page just doesn’t load correctly.

retries: 1

@tillschander we are also facing this issue on our Jenkins pipeline jobs, and again this is totally random any test gets error at any time, out of 50 test cases 2-3 fails due to this (2 workers), and if I increase the number of workers gradually then this count keeps increasing. (in all browsers). But if we run tests in local everything works fine. Any solution for this issue as this is impacting our daily automation build results. @zhanglei4333 @liuxingbaoyu @aslushnikov