In Playwright, what does a run-wide globalTimeout buy a CI pipeline that per-test timeouts cannot?

## What globalTimeout actually bounds `globalTimeout` is a top-level key in `playwright.config.ts`. It defaults to `0` — no limit — and bounds the **wall-clock duration of the whole run**: every worker, every project, and all the time that is not inside any individual test. When it expires the runner stops the run and reports a run-level timeout naming the budget, rather than a failure attached to a test. Nothing else in the config does this. `timeout` bounds one test, `expect.timeout` one assertion, `actionTimeout` one action — and none of them compose upwards. ## Why per-test budgets never add up to a run budget Take an internal admin console suite of 900 tests on 4 workers with a 30-second per-test budget: - the arithmetic ceiling is 900 × 30 s ÷ 4 ≈ 1 h 52 m, and every one of those tests is "within budget"; - retries multiply the worst case, because a retried test spends a full budget again; - fixture and hook time is charged to tests, but worker startup, browser launch and queueing between tests are charged to nobody; - a degraded environment slows everything a little, which appears nowhere as a per-test failure until something crosses 30 seconds. A run can therefore stall for hours without a single test misbehaving by its own clock. `globalTimeout` is the only budget that notices that. ## What it costs when it fires This is the part that decides how you use it: 1. The run is **truncated**. Tests that had not started produce no result of their own — you are missing data, not reading it. 2. There is no attribution. The error says the budget blew, not which test or fixture consumed it, so you go to the durations of what did finish, the reporter output, or the traces. 3. It is indistinguishable from a legitimately slower run: a cold image cache, a larger matrix, a shared environment under load. So a fired `globalTimeout` is a **capacity signal, not a defect report**. The response is to look at where the time went — not to reflexively raise the number, and certainly not to lower it in the hope that the suite gets faster. ## Sizing it 1. Start from the honest worst case: worst-case test duration × test count ÷ workers. 2. Add the multiplier for the retry policy you actually run. 3. Add setup, teardown and per-worker startup cost. 4. Add headroom for a bad day, so ordinary variance is not reported as a hang. 5. Round up, and revisit whenever the suite size or the worker count changes. A budget set just above the median run turns normal variance into red builds, and a team that sees the run-level red often enough stops reading it. ## How it sits next to the other run-level clocks | Clock | Scope | Who reports the failure | |---|---|---| | `timeout` | one test | Playwright, against that test | | `globalTimeout` | the whole run | Playwright, as a run-level error | | CI job limit | the whole job | the CI agent, by killing the process | The agent's own limit will eventually stop a stalled job, but it does so from outside: the process is killed and you are left with a red job rather than a run that ended on its own terms. A `globalTimeout` set somewhat below the job limit keeps the ending inside Playwright. ## Two mechanical notes worth knowing - The budget applies to *a run*, and each shard of a sharded suite is its own run in its own process — so a shard carries the whole `globalTimeout`, not a fraction of it. Splitting a suite across four jobs without revisiting the number quadruples the total time the estate will tolerate. - It is a wall-clock budget, not a CPU one. Adding workers reduces the elapsed time a given suite needs but does nothing to the budget itself, so worker-count changes and `globalTimeout` should move together rather than drift apart.