playwright suite passes on my laptop, 7 specs time out only on ubuntu-latest CI

No. The answer is workers: process.env.CI ? 2 : undefined.

That runner is 2 vCPU shared. Four chromium contexts plus your server plus node means everything is starved, and Playwright's actionability checks are the first thing to notice - before it clicks, it waits for the element to be stable across two animation frames, visible, and not covered. On a machine where a frame takes 400ms, "stable for two frames" stops being instant and starts being a race with your own animations.

That is exactly your symptom: the button is there in the screenshot, and the click is waiting, because the thing it is waiting for is not visibility.

Expand the failed action in the trace and you will find the stability line rather than a "not found" line. Two workers on a 2-core box is usually faster in wall clock than four, because you stop paying for retries.

Also check what webServer is actually waiting for. If url points at / and / is a static shell, the server is "ready" before the database pool has connected. Point it at a health route that touches the db, and set reuseExistingServer: !process.env.CI.

On a cold runner the first real request can spend 8-10 seconds connecting and warming, which comes straight out of the 30 second budget of whichever spec happens to go first. That also explains "never the same seven twice".

Bigger runners are real and cost roughly double per minute for double the cores. If the suite is on the critical path for every deploy that can be the cheapest fix you will ever buy. Do the workers change first though, otherwise you are paying more money for the same starvation with a longer wick.

Turn on trace: 'on-first-retry' and upload test-results/ as an artifact. Ten minutes of setup and it pays for itself the first time this happens while you are asleep.

If you want to reproduce it locally, run the suite pinned to two cores. Same starvation, on a machine where you can attach a debugger.

Set timeout: 60000 in the config and move on. CI is slower than your laptop. That is the whole story.

--shard=1/3 across three jobs gets you three 2-core machines in parallel for the same per-minute price. Combined with two workers each you end up with six contexts spread over six real cores instead of four fighting over two.