--- title: "Move bottlenecked jobs to faster runners" description: "Benchmark the same workload on faster hardware and compare elapsed time and cost before changing runner capacity." url: https://starsling.dev/ci-playbooks/techniques/faster-runners canonicalUrl: https://starsling.dev/ci-playbooks/techniques/faster-runners --- # Move bottlenecked jobs to faster runners Benchmark the same workload on faster hardware and compare elapsed time and cost before changing runner capacity. ## How to choose an approach Compare the examples by repository setup, prerequisites, and risks before adopting one. Each company implemented this in its own environment; measure each change against your own baseline. - **[Linear](https://starsling.dev/ci-playbooks/linear#faster-runners)**: Use it when Build or test execution still dominates after cheaper setup changes. Check before adopting: Match operating system, architecture, workload and event mix. Compare elapsed time, queue time and runner cost; StarSling sells a runner option worth benchmarking. - **[Mastra](https://starsling.dev/ci-playbooks/mastra#starsling-runners)**: Use it when One workflow sets the critical path and its jobs run on standard hosted runners. Check before adopting: Swap one workflow first and compare wall-clock p95 over matched windows before moving the rest. - **[OpenAI](https://starsling.dev/ci-playbooks/openai#faster-runner)**: Use it when The critical-path job is compute-bound and cheaper setup, cache and test fixes are exhausted. Check before adopting: Benchmark comparable workloads and include runner cost. Fork or event restrictions may require the existing label for some runs. - **[Ramp](https://starsling.dev/ci-playbooks/ramp#faster-cpu)**: Use it when Profiling the machine that runs the slowest test job shows the CPU saturated for most of the run. Check before adopting: A faster runner class bills at a different rate, so compare runner minutes and cost per run alongside elapsed time. ## Apply this technique ````text Evaluate and apply this CI technique to my repository: Move bottlenecked jobs to faster runners. Benchmark the same workload on faster hardware and compare elapsed time and cost before changing runner capacity. Read the technique and its source-backed company examples: https://starsling.dev/ci-playbooks/techniques/faster-runners.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. ```` ## How companies used this technique Read what each company changed and follow the original sources. ### Linear: Benchmark the same job on faster hardware Linear moved the same pipeline to runners with faster CPUs, higher-performance storage and better cache infrastructure. Across the two days either side of the switch, jobs ran 34% faster on average. Evidence: Documented technique Use it when: Build or test execution still dominates after cheaper setup changes. Before applying it: Match operating system, architecture, workload and event mix. Compare elapsed time, queue time and runner cost; StarSling sells a runner option worth benchmarking. [Read more in the Linear playbook](https://starsling.dev/ci-playbooks/linear#faster-runners) [Primary source](https://linear.app/now/ci-bottleneck-reworked#upgraded-infrastructure-and-tooling) ### Mastra: Move the slowest test workflow onto StarSling runners StarSling’s agent moved every job in Mastra’s Combined store Tests workflow onto StarSling runners. Follow-up PRs moved the memory, E2E, workspace, prebuild and changed-test workflows the same way. Evidence: StarSling-measured workflow cohort result StarSling measured Combined store Tests at 5.87x faster wall-clock p95 after the runner swap and the agents’ test fixes: 29m 56s to 5m 06s. Successful push and same-repository PR runs across all branches: Feb 21 to 24 before migration versus Apr 1 to 4, 2026 after. The after window was the highest-ranked of seven candidate windows. ([Source](https://starsling.dev/customers/mastra)) Use it when: One workflow sets the critical path and its jobs run on standard hosted runners. Before applying it: Swap one workflow first and compare wall-clock p95 over matched windows before moving the rest. [Read more in the Mastra playbook](https://starsling.dev/ci-playbooks/mastra#starsling-runners) [Primary source](https://github.com/mastra-ai/mastra/pull/13466) ### OpenAI: Put the slowest job on a faster runner Codex moved its Windows Bazel jobs, often the long pole for PR checks, from the default hosted runners to a dedicated runner group. Evidence: Source PR/commit evidence Windows Bazel jobs moved to a dedicated runner group ([Source](https://github.com/openai/codex/pull/24952)) Use it when: The critical-path job is compute-bound and cheaper setup, cache and test fixes are exhausted. Before applying it: Benchmark comparable workloads and include runner cost. Fork or event restrictions may require the existing label for some runs. [Read more in the OpenAI playbook](https://starsling.dev/ci-playbooks/openai#faster-runner) [Primary source](https://github.com/openai/codex/pull/24952) ### Ramp: Move a CPU-bound test suite to a faster CPU In July 2023 Ramp's Python monolith test suite took 45 minutes, about 38 of them in the pytest invocation. The team watched the resource usage of a machine running the suite and found it CPU bound. Moving the suite to a faster CPU was the first change they made and the single largest speedup of the project. Evidence: Company-reported result or observation 2023: The faster CPU made the tests run about 50% faster, the first step of the week that took the suite from 45 minutes to under 5. ([Source](https://builders.ramp.com/post/faster-python-tests-part-two)) Use it when: Profiling the machine that runs the slowest test job shows the CPU saturated for most of the run. Before applying it: A faster runner class bills at a different rate, so compare runner minutes and cost per run alongside elapsed time. [Read more in the Ramp playbook](https://starsling.dev/ci-playbooks/ramp#faster-cpu) [Primary source](https://builders.ramp.com/post/faster-python-tests-part-two) ## CI optimization is continuous work. Apply this technique yourself, or use StarSling Runners for faster GitHub Actions and optional agent-driven optimization PRs, which teams on eligible paid plans can turn on. [Get self-improving CI](https://starsling.dev/products/runners) ## Related techniques ### [Build each architecture on native runners](https://starsling.dev/ci-playbooks/techniques/native-architecture-builds) Run architecture-specific builds on matching hardware to avoid the overhead of emulation. 2 implementations · 2 companies (Spotify, Stripe) ### [Match test concurrency to the runner](https://starsling.dev/ci-playbooks/techniques/tune-test-workers) Measure worker counts against available CPU and memory. More workers help only while the runner has capacity. 4 implementations · 4 companies (Anthropic, Mastra, OpenAI, Stripe) ## Company Playbooks ### [Anthropic](https://starsling.dev/ci-playbooks/anthropic) Run only affected tests ### [DoorDash](https://starsling.dev/ci-playbooks/doordash) Run build and test in parallel, sharded across CI agents ### [Linear](https://starsling.dev/ci-playbooks/linear) Benchmark the same job on faster hardware ### [Mastra](https://starsling.dev/ci-playbooks/mastra) StarSling runners for the slowest test workflow ### [OpenAI](https://starsling.dev/ci-playbooks/openai) Rank CI fixes by the minutes they save ### [Ramp](https://starsling.dev/ci-playbooks/ramp) Move a CPU-bound test suite to a faster CPU ### [Shopify](https://starsling.dev/ci-playbooks/shopify) Let an agent iterate against one CI metric ### [Spotify](https://starsling.dev/ci-playbooks/spotify) Build arm64 on native arm64 runners ### [Stripe](https://starsling.dev/ci-playbooks/stripe) Run only the tests a change can reach ### [Uber](https://starsling.dev/ci-playbooks/uber) Build the merge-queue speculations most likely to be needed ## Related guides Implementation guides for this technique. ### [Cut CI queue time](https://starsling.dev/best-practices/github-actions/cut-queue-time) Measure wait-to-start time and examine concurrency groups and available capacity. ### [Right-size GitHub Actions runners](https://starsling.dev/best-practices/github-actions/right-size-runners) Compare runner sizes on the same workload and account for elapsed time and cost. ### [Diagnose high CI queue time](https://starsling.dev/github-actions/problems/high-queue-time) Check concurrency, cancellation, runner capacity, and triggers against run history.