Larger runners are a checkbox and a bill

October brought configurable runner sizes, which turns a slow pipeline into a pricing question rather than an engineering one.

jobs:
  build:
    runs-on: ubuntu-latest-8-cores

# measured first, on the standard runner:
#   peak memory 6.1 GB of 7 GB available → swapping
#   wall clock 18m40s, of which 11m was the JS build

# on 8 cores / 32 GB:
#   peak memory 6.2 GB, no swap
#   wall clock 6m10s
#   cost per run: about 4x

Measuring what a job actually uses before upgrading is the step that gets skipped, and it is what distinguishes a memory-bound job — where a larger runner is transformative — from a network-bound one, where it changes nothing and costs four times as much. A pipeline running two hundred times a day is a real line on a bill, and the arithmetic is worth doing once.