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

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