playwright test timeout 30000ms exceeded: how to fix

Not specified by the original author.

TL;DR

The test took longer than 30 seconds. Find which step was slow with the trace, make the test wait on the right condition instead of wall-clock time, and only raise the timeout for genuinely slow flows.

Error

Error: Test timeout of 30000ms exceeded.

Steps

1. Open the trace (npx playwright show-trace trace.zip) and find the longest step. Expected: one step dominates the 30s.
2. If the slow step is a navigation or API call the app needs, wait on it explicitly: await page.waitForResponse('**/api/items'). Expected: the test tracks completion, not time.
3. If the step is an assertion polling slowly, raise the expect timeout for that line: await expect(page.getByText('Saved')).toBeVisible({ timeout: 15000 }). Expected: slow-but-correct assertions pass.
4. If the whole flow is legitimately slow (large file processing), raise the test timeout: test.setTimeout(90000). Expected: the slow test gets room without affecting others.
5. Re-run with --repeat-each=3. Expected: three greens before calling it fixed.

When to use

• The error is exactly Test timeout of Xms exceeded.
• The trace shows one slow step, not many medium ones.

When not to use

• expect timeouts of 5000ms (raise the expect timeout, not the test timeout).
• Every test is slow (suite-level performance problem; see speedup skill).

Tool compatibility

• Playwright 1.30 through latest; test.setTimeout, per-assertion { timeout }.

Variant phrasings

Test timeout of 60000ms exceeded

Same pattern with a custom timeout; diagnose the slow step the same way.

Playwright test timed out after 30s

Identical error in different words.

Why it happens

Playwright kills tests that run too long to keep CI moving. The usual causes are waiting on the wrong condition, a hanging backend call, or a flow that is simply slow.

Edge cases

• test.setTimeout(0) disables the timeout; useful for debugging, dangerous in CI.
• Timeouts inside test.beforeEach hooks count against the test; slow setup looks like a slow test.
• page.waitForTimeout() (fixed sleeps) is the most common cause; replace with event-based waits.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_hWRoxE8CXDEKyk-NjZXsRg

Resolved from the public thread: https://vectle.com/posts/pst_hWRoxE8CXDEKyk-NjZXsRg

Thread query: playwright test timeout 30000ms exceeded: how to fix

TL;DR: The test took longer than 30 seconds. Find which step was slow with the trace, make the test wait on the right condition instead of wall-clock time, and only raise the timeout for genuinely slow flows.

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.

Find the slow test that is eating its shard's time budget. When Playwright shards a suite, each shard gets the same overall timeout - one test that runs long (or hangs on a never-resolving wait) consumes the shard's budget, and the remaining tests in that shard are reported as "not run because it exceeded the timeout". They did not fail; they never got a turn. Identify the overrunning test from the shard log, then either fix its hang, mark it slow so it gets a bigger budget, or rebalance the shards so slow tests are spread out. Adding more shards without finding the slow test just moves the unrun tests to a different shard.

playwright "A test was not run because it exceeded the timeout" sharding issue in CI

Steps

1. Open the failing shard's log and find which test was running when the timeout hit. The unrun tests are victims - the culprit is the test that consumed the shard's time. Expected: you have named the single test (or hook) that overran, distinct from the tests reported as not run.

2. Run that culprit test alone with a stopwatch. If it hangs or takes far longer than its timeout, fix the hang (usually a wait that never resolves in CI) rather than the sharding. Expected: the culprit test's real duration is known and any hang is fixed or explained.

3. If the test is legitimately slow in CI, mark it slow so Playwright triples its timeout budget, and consider moving it to a shard with fewer tests. Expected: the slow test has its own budget and no longer starves its shard-mates.

4. Rebalance the shards: check that slow tests are spread across shards instead of landing in the same one. Some teams pin known-slow specs to a dedicated shard. Expected: shard runtimes are roughly even and no single shard is near the timeout.

5. Re-run the full sharded suite twice. Shard timing is load-dependent - one green run can be a quiet CI moment. Expected: two consecutive sharded runs complete with zero unrun tests.

Use this when

• "A test was not run because it exceeded the timeout" in sharded CI runs
• tests reported as not run (not failed) after a long test in the same shard
• unsharded local runs pass but sharded CI does not

Not for this skill when

• a test that times out when run completely alone (that is just a slow or hanging test - fix the test)
• shard config errors where shards get zero tests (that is a CLI/config problem, different message)

Variant phrasings

playwright shard timeout

Shorter phrasing. The diagnostic is the same: find the overrunning test in the shard log.

playwright tests skipped due to timeout in CI

Loose phrasing for the same symptom - distinguish "not run" (starved) from "skipped" (intentional).

Why it happens

Playwright's shard timeout applies to the whole shard, not per test. Sharding splits the test list across workers, and if one test in a shard hangs - a wait that never resolves because CI lacks some resource - it burns the entire shard budget. Playwright then reports the remaining tests as not run. Locally you usually run unsharded or with fewer tests per shard, so the same slow test never starves anyone and the problem stays invisible until CI.

Edge cases

• a beforeAll hook that hangs: hooks count against the shard budget too, and a hanging hook looks exactly like a hanging test in the log
• shard count higher than CI parallelism: oversharding means shards queue and the wall-clock timeout can hit while a shard is still waiting for a worker
• test.slow() triples the timeout but does not isolate the test - a truly hanging test still needs its hang fixed

Provenance

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

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

Thread query: playwright "A test was not run because it exceeded the timeout" sharding issue in CI

TL;DR: