Match test concurrency to the runner

Measure worker counts against available CPU and memory. More workers help only while the runner has capacity.

Prompt

Evaluate and apply this CI technique to my repository: Match test concurrency to the runner.

Measure worker counts against available CPU and memory. More workers help only while the runner has capacity.

Read the technique and its source-backed company examples: https://starsling.dev/ci-playbooks/techniques/tune-test-workers.md

Inspect this repository’s CI workflows, build and test commands, dependencies, and recent run timings. Identify where this technique applies and explain the expected benefit using this repository’s evidence.
Measure a baseline from recent comparable runs: elapsed time, queue time, runner minutes and failures where available. If data is unavailable, say what cannot be measured.
Compare relevant company approaches, checking prerequisites, platform differences and tradeoffs. Rank applicable options by evidence, fit and measurable opportunity; do not present company results as predictions for this repo.
Recommend the smallest safe change, show what checks and fallback paths remain, and ASK ME WHICH CHANGE TO APPROVE BEFORE EDITING ANY FILES.
Only after approval, work on a new feature branch, make one reversible change, and open a reviewable pull request. Never merge or push to a default or protected branch.
Keep required checks, test coverage, deployment and release behavior intact. Validate the change and compare equivalent runs where possible; report limitations and what should be monitored after merge.

View all playbooks

How companies used this technique

Read what each company changed and follow the original sources.

Set test worker width from the actual host

Bun removed the CPU and thread caps that held its Linux test agents to two usable cores, and sized the parallel test width from the available cores. A follow-up capped the width at four on macOS, where each M2 Ultra host runs two tart virtual machines and every coordinator forks its own workers.

Use it when: A fixed worker count has never been measured, or workers contend for memory, physical cores or a shared host.
Before applying it: Nested worker processes and other virtual machines on the same host count toward the width.

Fit test concurrency to the runner’s memory

The memory integration configuration capped Vitest threads at two after the source reported runner disconnects and memory pressure.

The source reports 61 failures in 771 runs. Source

The current Vitest configuration expresses the limit as maxWorkers: 2. Source

Use it when: Parallel tests and build output compete for limited runner memory.
Before applying it: Preserve the separate build heap requirement and measure peak memory, elapsed time and failures across worker counts.

Measure how many tests to run at once

Codex compared Windows Bazel shards at 4, 8 and 12 local test jobs in a forced-test-execution experiment, then set the CI default to 8 with one .bazelrc line. Sharding spreads work across runners; this tunes how much runs at once on each runner.

Slowest shard: 835.5s to 609.3s at 8 local test jobs, in the experiment the PR cites Source

Use it when: Test parallelism is a default or a guess for this runner.
Before applying it: More parallel workers can increase memory pressure and contention. Compare the same workload and runner, including reliability and total minutes.

Measure workers against the runner

Stripe iOS tried six simulator workers and kept four, which was faster and more reliable, and split Crypto UI tests into separate classes so Xcode could run them in parallel. Stripe Android sized individual device-heavy lanes and raised its managed-device ceiling to match its six shards. Metronome, a Stripe company, moved a publishing job whose doc build was timing out to an 8-core runner, on a suggestion from the Stainless team.

In the same combined runs, the Crypto UI test step went from about 10 to about 6 minutes. Source

Use it when: Tests run serially, or worker counts and runner sizes were chosen without measurement.
Before applying it: Isolate shared accounts and ports before adding workers, and keep tests that verify serial behavior in a serial lane. Measure each change separately; the source PRs changed workers and machines together.

How companies used this technique

Set test worker width from the actual host

Fit test concurrency to the runner’s memory

Measure how many tests to run at once

Measure workers against the runner

Related techniques

Build the test database once for all workers

Isolate state before running tests in parallel

Move unit tests to a parallel-by-default framework, gated on ten clean runs

Company Playbooks

Related guides

Shard tests across parallel jobs

Cut repeated test setup

Diagnose slow tests in CI

Optimize Playwright tests

Make Vitest run mode explicit

Parallelize independent jobs