playwright Test timeout of 30000ms exceeded on expect.poll in CI but not

Not specified by the original author.

Give the poll loop room to breathe on CI, or find out the condition never becomes true there. expect.poll retries its assertion until it passes or the test timeout hits - on a slow CI runner each poll cycle costs more, so a poll that converges in 5 seconds locally can eat the full 30 second test timeout in CI. First lengthen the test timeout for that spec (or mark it slow on CI); then look at the poll intervals so you are not hammering a slow endpoint hundreds of times. If it still times out, stop tuning and check the condition itself: the state the poll waits for may never happen in CI because of missing seed data or a disabled feature. A poll that can never pass will burn any timeout you give it.

playwright "Test timeout of 30000ms exceeded" on expect.poll in CI but not locally

Steps

1. Mark the test as slow for CI or raise its individual timeout. This is a diagnostic step: if the test goes green with more time, the poll logic is fine and CI is just slow. Expected: the test passes with a longer timeout, proving the poll converges eventually.

2. Tune the poll itself: set explicit polling intervals instead of the default rapid retry, so each attempt has time to see a settled state and you are not spamming a slow CI backend. Expected: fewer, better-spaced poll attempts and the same eventual pass.

3. Check what the poll waits on in the CI environment: seed data, feature flags, background jobs. Run the poll condition manually against the CI-like environment and see if it ever becomes true. Expected: you have confirmed the polled state is reachable in CI, not just locally.

4. If the condition depends on a background job or async pipeline, make the test trigger or await that work explicitly instead of polling blindly for the full timeout. Expected: the test waits on the actual cause rather than polling a side effect.

5. Keep the timeout change scoped to the slow spec. A global timeout bump hides the next real slowdown across the whole suite. Expected: only the polling spec carries the higher timeout; the suite default is unchanged.

Use this when

• "Test timeout exceeded" specifically on expect.poll, CI-only
• a poll that converges locally but not within the timeout on CI
• you need to separate "slow CI" from "condition never true in CI"

Not for this skill when

• expect.poll failing fast with an assertion error rather than a timeout (that is a wrong expectation, fix the assertion)
• the polled condition never becoming true locally either (that is an app bug - file it against the app)

Variant phrasings

playwright expect.poll timeout

The general form. CI-only adds the slow-runner versus unreachable-condition fork.

test timeout exceeded playwright CI

Broader phrasing. When poll is in the stack, treat it as a polling problem first.

Why it happens

expect.poll wraps an assertion in a retry loop bounded by the test timeout, not by its own limit. Locally the loop converges quickly because every poll cycle is fast; in CI each cycle is slower (loaded CPU, slower network to the app under test), so the same number of cycles consumes far more wall-clock time and the test timeout fires first. Separately, if the state being polled depends on CI-specific setup that is missing, the loop retries until the timeout no matter how long you make it - which is why the reachability check matters more than the timeout value.

Edge cases

• polling an external service with rate limits: rapid default retries can get your CI IP throttled, making the poll slower the longer it runs
• expect.poll inside a test that also has a tight expect timeout: the two timeouts interact - the poll inherits the test timeout unless told otherwise
• flaky pass after lengthening the timeout: if it passes sometimes at the longer timeout, the condition is racy in CI - fix the underlying timing instead of the timeout

Provenance

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

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

Thread query: playwright "Test timeout of 30000ms exceeded" on expect.poll in CI but not locally

TL;DR:

Not specified by the original author.

TL;DR

CI runners are weaker than your laptop, and a starved event loop makes fixed waits expire early. waitForTimeout waits on the clock, not on the app, so on a throttled runner the timeout fires before the app has had a chance to respond. Replace fixed waits with condition-based waits that wait for the state you actually need.

The query

agent saw waitForTimeout pass locally and fail in CI  -  it didn't know the CI runner throttles the event loop

Steps

1. Confirm the divergence is a timing gap, not a bug

Check that the same step passes locally and fails in CI with a timeout, and that the app eventually reaches the expected state in CI if you wait longer manually. Also check the CI runner's specs (CPU count, throttling) against your machine.

Expected: confirmation that the app works in CI, just slower, and the runner is weaker than local.

2. Replace fixed waits with condition-based waits

Swap every waitForTimeout for a wait on the actual condition: wait for the selector, the text, the network response, or the app state you need. Condition-based waits succeed as soon as the app is ready and only time out when something is genuinely wrong.

Expected: the test waits on app state, not wall-clock time. No fixed sleeps remain on the critical path.

3. Size unavoidable timeouts for the weakest runner

Where a timeout is truly needed, set it from the CI runner's specs, not your laptop's. A good rule: the timeout should be generous on the slowest supported runner, and the test should still fail fast on a genuinely broken app (condition waits give you that).

Expected: timeouts documented with the runner they were sized for.

4. Re-run on CI without touching the app

Run the updated test on the same CI runners that were failing. It should pass with no application changes.

Expected: green on CI, with the test now robust to runner speed differences.

Use this when

• Playwright waits pass locally and time out in CI
• The CI runner has fewer CPUs or is otherwise slower than dev machines
• The test uses waitForTimeout or fixed sleeps anywhere
• The agent's "fix" was to increase the fixed wait (that just moves the cliff)

Not for this skill when

• The wait fails locally too (then the app is actually broken or the condition is wrong)
• The app never reaches the expected state even with generous waits (that is a real bug, not throttling)
• CI runners are as fast as local machines (look elsewhere: network, services, data)
• The flakiness is in selectors or test isolation, not timing

Variant phrasings

test is green on a dev machine, red on every CI run

Runner-speed divergence is the first suspect. Compare specs before debugging the app.

agent bumped waitForTimeout from 1s to 5s and it still flakes in CI

Fixed waits on a throttled loop are a moving target. No number is right; the pattern is wrong.

animations and transitions never finish in time on CI

Same root cause. Wait for the end state (the element's final class, the settled DOM), not for the animation's expected duration.

Why it happens

The agent develops and verifies locally, where the event loop is fast and fixed waits are generous. It never models the CI runner as a different machine: fewer CPUs, shared tenancy, throttled loops. So a 1s wait that is comfortable locally becomes marginal in CI, and the agent reads the timeout as app misbehavior rather than runner weakness. Its instinct to lengthen the wait preserves the broken pattern instead of replacing it with waits that don't depend on runner speed at all.

Edge cases

• The CI runner is throttled dynamically (burst then throttle): durations vary run to run. Condition-based waits handle this; any fixed number won't.
• Some waits are genuinely time-based (debounce, polling intervals): for those, wait for the post-timeout state with a condition, and size the timeout from the slowest runner plus margin.
• The app is slow in CI for a real reason (cold caches, slow services): condition waits will pass but slowly. That is correct behavior; track the durations separately as a performance signal.
• Local runs are also throttled (power save, background load): reproduce CI conditions locally by constraining CPU, so you can verify the fix without pushing.

Provenance

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

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

Thread query: agent saw waitForTimeout pass locally and fail in CI - it didn't know the CI runner throttles the event loop

TL;DR: CI runners are weaker than your laptop, and a starved event loop makes fixed waits expire early. waitForTimeout waits on the clock, not on the app, so on a throttled runner the timeout fires before the app has had a chance to respond. Replace fixed waits with condition-based waits that wait for the state you actually need.

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: