playwright waiting for getByRole('button') to be visible timeout o

Not specified by the original author.

Figure out whether CI is slow or the button is really missing. A getByRole timeout on CI-only usually means one of two things: the page takes longer to reach the state where the button appears (slow network, slow backend, cold cache), or the button never appears in CI because the environment differs (feature flag, seed data, auth state). Turn on tracing for the failing test, watch where the time goes, and only then decide: raise the timeout if the button does appear eventually, fix the environment if it never does. Raising the timeout on a button that never appears just makes the suite slower and still red.

playwright "waiting for getByRole('button') to be visible" timeout only on CI: debugging

Steps

1. Capture a trace of the failing CI run: enable tracing (retain on failure is enough) and download the trace artifact. Open it and watch the timeline around the failing wait. Expected: you can see exactly what the page looked like while Playwright was waiting - spinner, blank page, or the button already there.

2. Check whether the button appears at all in the trace. Scrub to the end of the timeout: if the button is visible in the final screenshot, CI is just slow; if it never appears, the environment is wrong. Expected: you have classified the failure: slow (button eventually shows) versus missing (button never shows).

3. If slow: raise the timeout for this wait or mark the test slow on CI rather than changing the locator. Also check what the button waits on - a slow API response in CI is the usual culprit, and the fix may belong in test data setup, not the test. Expected: the test passes with the higher timeout and the extra time is explained by a known slow step.

4. If missing: diff the CI environment against local - feature flags, seeded data, auth session, base URL. The button is probably gated behind something CI does not set up. Expected: you found the environmental difference and the button appears once it is fixed.

5. Add the missing setup (or the documented timeout) to the shared fixtures so the next test hitting this page does not rediscover the same problem. Expected: the fix lives in shared setup, not copy-pasted into one test.

Use this when

• getByRole (or any locator) wait-for-visible timeouts that happen only in CI
• you need to tell "CI is slow" apart from "CI is different"
• a button gated behind async work like API calls or auth

Not for this skill when

• "strict mode violation: resolved to N elements" (that means the locator matches too much, not too little)
• a button that never appears locally either (that is an app bug - file it against the app)

Variant phrasings

playwright getByRole timeout

Same error without the CI-only qualifier. The debugging path is identical, but CI-only adds the environment-diff step.

waiting for locator to be visible exceeded timeout

The generic form. getByRole is just the locator flavor; the slow-vs-missing classification applies to all of them.

Why it happens

getByRole queries the accessibility tree, so it only matches when the button is actually exposed to assistive tech - after render, after data loads, after any gating logic runs. CI stretches every one of those steps: slower CPUs render later, colder caches fetch later, and CI-specific config (flags, seed data) can gate the button entirely. The timeout message looks identical for "slow" and "missing", which is why the trace check comes before any fix.

Edge cases

• the button appears in the trace but the test still times out: check for overlapping elements or pointer-events issues - visible to the accessibility tree is not the same as clickable
• CI runs against a preview deployment with different data URIs seed the data the button depends on, or the timeout will return
• raising timeouts globally in playwright config: fine as a diagnostic, but a suite-wide timeout bump hides real slowdowns - scope it to the slow test

Provenance

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

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

Thread query: playwright "waiting for getByRole('button') to be visible" timeout only on CI: debugging

TL;DR:

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.

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.