playwright waiting for selector timeout: debugging

Not specified by the original author.

TL;DR

Playwright auto-waits, so a selector timeout means the element never reached an actionable state. Use the inspector to test the locator live, then fix the locator, the visibility precondition, or the app state.

Error

Error: locator.waitFor: Timeout 5000ms exceeded.
waiting for locator('[data-testid="checkout"]') to be visible

Steps

1. Run with --debug and use the Playwright Inspector to evaluate the locator against the live page. Expected: you see whether it matches zero, one, or many elements.
2. If it matches zero, fix the locator: prefer getByRole, getByTestId, or getByText over CSS. Expected: exactly one match.
3. If it matches but is hidden, reproduce the user steps that reveal it (open the menu, complete the form). Expected: the locator becomes visible through the real flow.
4. If the element appears after data loads, wait on the data URIs await page.waitForResponse('**/api/cart') before the locator. Expected: deterministic instead of racy.
5. Only then consider raising the timeout: locator.waitFor({ state: 'visible', timeout: 15000 }). Expected: used sparingly, on the slow locator.

When to use

• locator.waitFor or auto-wait timeouts at the default 5s.
• The inspector shows the locator state clearly.

When not to use

• Test timeout of 30000ms (whole-test slowness).
• strict mode violation (too many matches, not zero).

Tool compatibility

• Playwright 1.30 through latest; --debug inspector.

Variant phrasings

waiting for getByRole to be visible timed out

Same diagnosis; role locators are preferred but still need the element to exist.

locator never became stable

The element matched but kept moving (animation); wait for the animation to end.

Why it happens

Auto-waiting checks actionability: attached, visible, stable, enabled. A timeout names which check never passed, which points at the cause.

Edge cases

• state: 'attached' passes for hidden elements; use it only when visibility is genuinely not required.
• Elements in closed shadow roots are invisible to all locators; that is a testability bug to fix in the app.
• Animations that never settle (spinners) make stable never pass; assert on the loaded state instead.

Provenance

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

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

Thread query: playwright waiting for selector timeout: debugging

TL;DR: Playwright auto-waits, so a selector timeout means the element never reached an actionable state. Use the inspector to test the locator live, then fix the locator, the visibility precondition, or the app state.

Not specified by the original author.

TL;DR

Playwright's default 30-second selector wait is strict: if the element is hidden, detached, or never renders, you get TimeoutError. Wait for the right state (visible vs attached), confirm the selector matches in the live DOM, and only then raise the timeout.

playwright TimeoutError waiting for selector during scrape

Use this when

• wait_for_selector or a locator action throws TimeoutError.
• The element shows in a manual browser but not in the script.
• Scrapes work on some pages and fail on others.

Not for this skill when

• Navigation itself times out. That is a navigation problem.
• The page returns an error status. Fix the request first.

Steps

1. Print what the page actually rendered: print(await page.content()) and search for your selector text. Verify: you can see whether the element exists at all.
2. Test the selector in the browser devtools console on the live site. Verify: document.querySelector finds it there.
3. Match the wait to the need: await page.wait_for_selector('.price', state='visible', timeout=10000). Verify: no timeout on a page where the element renders.
4. If the element renders late (lazy load, infinite scroll), scroll or wait for network idle first, then wait for the selector. Verify: the element appears after the scroll.
5. For flaky dynamic pages, wrap the wait in a retry loop of 3 attempts with a page reload between attempts. Verify: the scrape succeeds on at least 9 of 10 runs.

Variant phrasings

playwright waitforselector timeout

Same failure, API-name search.

locator timeout playwright scrape

The locator-API variant.

playwright element not found timeout

Symptom-level search.

Compatibility: Playwright for Python and Node. Timeouts are in milliseconds in both. Default is 30000.

Why it happens

Playwright waits until the selector matches AND the element reaches the requested state. Pages that lazy-load, A/B test layouts, or render behind auth show a different DOM to the script than to your manual browser, so the selector never matches and the wait burns its full timeout.

Edge cases / pitfalls

• visible fails on elements that exist but are hidden. Use attached when you only need the node in the DOM.
• Single-page apps re-render and detach nodes. Re-query the locator after each navigation instead of reusing a stale handle.
• Raising the timeout on a selector that can never match just waits longer. Verify the selector first, raise second.

Provenance

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

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

Thread query: playwright TimeoutError waiting for selector during scrape

TL;DR: Playwright's default 30-second selector wait is strict: if the element is hidden, detached, or never renders, you get TimeoutError. Wait for the right state (visible vs attached), confirm the selector matches in the live DOM, and only then raise the timeout.

Not specified by the original author.

TL;DR

First check whether the locator resolved to zero elements or more than one; most 5000ms timeouts are a wrong name or a strict-mode violation, not a slow page. Fix the locator or disambiguate it, then raise the timeout only for genuinely slow UI. Blindly bumping the timeout hides broken selectors.

Error

TimeoutError: locator.click: Timeout 5000ms exceeded.
Call log:
  - waiting for getByRole("button", { name: "Submit" })
  -   locator resolved to 0 elements

Steps

1. Re-run the single test with --debug or open the trace to see the resolved element count. Expected: you see "resolved to 0 elements" or "resolved to 2 elements" in the call log.
2. If zero elements: fix the role or accessible name to match what the app renders (check the accessibility snapshot in the trace viewer). Expected: the locator resolves to exactly 1 element.
3. If two or more elements: tighten the locator with a more specific name, chain .first(), or scope it inside a parent locator. Expected: the locator resolves to exactly 1 element.
4. Only now, if the element is real but slow, pass an explicit timeout: page.getByRole('button', { name: 'Submit' }).click({ timeout: 15000 }), or set timeout under use in the config. Expected: the test passes consistently on slow runs.

When to use

• An action (click, fill, check) or assertion on a getByRole locator fails with a 5000ms timeout.
• The call log shows the locator resolved to 0 or 2+ elements.
• You need to decide between fixing the selector and raising the timeout.

When not to use

• The timeout is on a network request or API call, not a locator.
• The whole test hits the test-level timeout (different setting, timeout in config).
• You are waiting on navigation or a URL change rather than an element.

Tool compatibility

• Playwright 1.40 through 1.5x, @playwright/test runner.
• Applies to Chromium, Firefox, and WebKit identically.

Variant phrasings

locator.getByRole timed out waiting for element

Same failure surfaced on a different action (fill, check, hover). Same diagnosis steps.

waiting for getByRole resolved to 0 elements

The call-log line that tells you the selector matched nothing. Fix the role or the accessible name.

Why it happens

The default action timeout is 5000ms, and the locator keeps waiting for the element to become actionable (attached, visible, stable, enabled). Strict mode requires exactly one match, so zero matches or multiple matches both burn the full timeout before Playwright throws.

Edge cases

• Passes locally, fails in CI: CI is slower, raise the timeout or fix a race instead of blaming the selector.
• Flaky on re-renders: use a toBeVisible assertion with auto-retry instead of a manual wait.
• Still times out after the fix: the element may live inside an iframe, scope the locator with frameLocator.

Provenance

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

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

Thread query: playwright getByRole timed out after 5000ms

TL;DR: First check whether the locator resolved to zero elements or more than one; most 5000ms timeouts are a wrong name or a strict-mode violation, not a slow page. Fix the locator or disambiguate it, then raise the timeout only for genuinely slow UI. Blindly bumping the timeout hides broken selectors.