Right-size GitHub Actions runners without slowing CI

Runner size follows measured job behavior, not a repository-wide default. Test the same commit and command on the current runner and a smaller candidate, keep caches and inputs identical, compare a distribution of successful runs, and change the production label only when the candidate preserves pass rate and wall-clock. Short jobs that mostly wait on checkout, an API, or one single-threaded command are the strongest candidates.123

# Set CI_BASELINE_RUNNER and CI_SMALL_RUNNER to real labels in
# Settings > Secrets and variables > Actions > Variables.
on:
  workflow_dispatch:

jobs:
  validate-runner-size:
    strategy:
      fail-fast: false
      matrix:
        runner:
          - ${{ vars.CI_BASELINE_RUNNER }}
          - ${{ vars.CI_SMALL_RUNNER }}
        # Ten samples per arm expose normal variance instead of comparing two lucky runs.
        sample: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
    name: ${{ matrix.runner }} · sample ${{ matrix.sample }}
    runs-on: ${{ matrix.runner }}
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v6
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run validate-package-json

A short or single-threaded job pays the larger runner's rate while checkout, network waits, and one command leave the extra cores idle.

jobs:
  validate-package-json:
    # This job checks out, sets up Node, and runs one short validator.
    # A larger runner is inherited without evidence that the job uses it.
    runs-on: ${{ vars.CI_LARGE_RUNNER }}
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v6
        with:
          node-version: 22
      - run: npm run validate-package-json

Mastra had two generations of the same measured opportunity: short validation and orchestration jobs running on a 4-vCPU label even though their work could not use the extra cores. StarSling agents moved them to the 2-vCPU tier only after same-commit comparisons showed no meaningful wall-clock penalty.

• Read the Mastra customer story
  Customer story

  Merged 2026-07-03

  perf(ci): move validate-pkg-json to the 2-vCPU StarSling runner, same wall-clock

  The validate-pkg-json job does only a checkout, setup-node, and one validator script with no CPU-parallel install. A 10-runs-per-arm comparison found no meaningful wall-clock difference, so StarSling moved it from the 4-vCPU runner to the 2-vCPU tier and halved its per-minute rate.

  Read the Mastra customer storyView PR #18871 in mastra-ai/mastra (opens in new tab)
• Read the Mastra customer story
  Customer story

  Merged 2026-08-19

  perf(ci): run the four jobs with no install on the 2-vCPU runner, 2× cheaper

  StarSling extended the measured right-size to four jobs that start no install, build, or test. A 50-run same-commit A/B found no measurable time penalty, while the 2-vCPU tier cut the per-minute rate in half.

  The blobless checkout is a separate supporting optimization. The right-sizing claim comes from the four runner-label changes and the A/B evidence, not from partial clone alone.

  Read the Mastra customer storyView PR #21824 in mastra-ai/mastra (opens in new tab)

Use the same commit, command, dependency versions, cache state, and runner pool for both arms. Compare successful-run medians and tails across enough repetitions to include normal variance, and inspect CPU and memory before interpreting the result. A smaller runner is safe only when it preserves the job's pass rate and its place on the critical path. One lucky run is not an A/B test.

GitHub bills hosted-runner time in whole-minute increments, so a job that finishes in seconds can cost a full minute on either size. Right-sizing lowers cost when the smaller SKU has a lower rate and the billed-minute count stays the same. It does not justify slowing a merge-gating build or test: if the smaller runner moves the workflow's critical path, keep the larger runner and optimize the work instead.

Runner cost is rate multiplied by billed time. Extra cores help only when the job has parallel CPU work that can use them; they do little for API calls, checkout, fixed network waits, or a short single-threaded validator. Measuring job by job avoids both failure modes: paying for idle capacity everywhere, or shrinking a compute-bound job until developer wait gets worse.

Hand this prompt to your coding agent (Claude Code, Cursor, and the like) to audit and fix this practice in your own repo.

Audit this repository's GitHub Actions runner sizes job by job. Use recent successful job history to identify frequent jobs whose own work is short or mostly waits on checkout, setup, APIs, or one single-threaded command, then compare their current runner label and per-minute rate with a smaller same-platform candidate. Do not assume smaller is safe from YAML alone. For the best candidate, create a branch-only A/B that runs the same commit, commands, cache state, and inputs on both labels; compare pass rate, median, P95, billed minutes, and any CPU or memory pressure across repeated runs. Change the production runs-on label only if the smaller arm preserves the merge gate and does not add failures, OOMs, timeouts, or reruns. Leave CPU-bound builds, parallel tests, memory-heavy jobs, and Docker builds unchanged unless the data proves equivalence. Show the evidence, choose only the highest-confidence job, and open a PR rather than applying it blindly.

Ground these changes in the upstream docs before you edit: https://docs.github.com/en/billing/reference/actions-runner-pricing, https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables, https://docs.starsling.dev/runners/instance-types. If you cannot fetch them, say so rather than guessing, and cite what you used in the PR description.

If you do not know why a run is slow yet, start with the diagnostic guide. Let an agent find which of these applies: /ci-speedup. If your workflows are already optimized but still slow, see our guide to fast GitHub Actions and GitHub Actions runner alternatives. Building containers in CI? The Docker workflow guide covers layer caching end to end. Want to see how your configuration measures up before changing anything? CI Score grades workflow config against a pass/fail rubric of these practices. It is not a speed measurement.

• GitHub Actions too slow
• Fast GitHub Actions
• GitHub Actions alternatives
• GitHub Actions pricing
• Self-hosted GitHub Actions runners
• Docker CI on GitHub Actions
• Install the free /ci-score skill to improve your GitHub Actions setup