playwright A test was not run because it exceeded the timeout sharding i

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:

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.

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.