What macOS runner minutes cost on GitHub Actions, and how to cut them

The prices

Per-minute rates for GitHub-hosted runners, from GitHub’s Actions runner pricing reference:

Larger runners are available on the Team and Enterprise Cloud plans only, and are billed even for public repositories.

How billing counts

• Per job, rounded up. “GitHub rounds the minutes and partial minutes each job uses up to the nearest whole minute.” Three macOS jobs of 4 min 10 s are billed as 15 minutes, not 12.5.
• Included usage is money, not minutes. Each plan includes compute per month: $12 on Free, $18 on Pro and Team, $300 on Enterprise Cloud. Runner usage is deducted at the rates above, so $12 is about 193 macOS minutes and $300 about 4,838.
• Public repositories use standard GitHub-hosted runners for free; larger runners are billed.
• Self-hosted runners are free on GitHub’s side and do not use the included amount. You pay for the Mac, its upkeep and its security instead.
• Failed and re-run jobs count. GitHub’s own example: a 10-minute workflow that fails after 5 and is re-run costs 15 minutes.

A worked month

An example team, numbers chosen to be easy to follow. Put in your own:

• 30 pull requests a week, 4 pushes each: 120 runs.
• 30 merges to the default branch a week, which run the same job: 30 runs.
• One job, build and test, 20 minutes on macos-26.

Every minute taken off that job is worth 650 minutes, about $40, a month. That is the yardstick for the levers below.

Seven levers

1. Cancel runs that a newer push replaced

On a pull request, only the run for the latest commit matters. A concurrency group per branch cancels the older run when a new one starts. Keep default-branch runs, which other things may depend on:

concurrency:  group: ${{ github.workflow }}-${{ github.ref }}  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

In the example, if one push in four arrives while the previous run is halfway, this saves about 1,300 minutes a month, $81.

2. Don’t start macOS for changes that can’t affect it

on:  pull_request:    paths-ignore:      - '**.md'      - 'docs/**'      - '.github/ISSUE_TEMPLATE/**'

One catch: a workflow skipped by a path filter leaves its checks “Pending”, and a pull request that requires them cannot merge. If the job is a required check, keep the workflow running and skip the expensive steps inside it instead, or make a cheap Linux job the required check.

3. Cap hung jobs

A job’s default timeout is 360 minutes. A Simulator that never boots or a test that waits forever costs 360 × $0.062 = $22.32 per job. Set a ceiling a little above your slowest normal run:

jobs:  build:    runs-on: macos-26    timeout-minutes: 30

4. Move everything that isn’t Xcode to Linux

Linting, formatting checks, danger-style pull request checks, documentation builds and anything that only needs a shell run at a tenth of the price on ubuntu-latest. Split them into their own job so the macOS job only builds and tests.

5. Stop recompiling what didn’t change

Most of an iOS job is usually compilation. Caching DerivedData looks like the fix and mostly isn’t: why caching DerivedData doesn’t speed up Xcode builds. Cache Swift package checkouts by Package.resolved, and for compiled code use Xcode 26’s compilation cache with a cache that outlives the runner (how, and what it takes).

6. Run only the tests the change reaches

Tests are the other large share. Two things help regardless of tooling: boot the Simulator explicitly before the test step, so the boot doesn’t hide inside the first test’s timeout, and run only what a pull request can affect, with xcodebuild -only-testing: or -skip-testing:. Keep running everything on the default branch, so anything selection skipped is caught one push later.

- run: |    UDID=$(xcrun simctl list devices available -j | jq -r '[.devices[][] | select(.name == "iPhone 17")][0].udid')    xcrun simctl bootstatus "$UDID" -b    xcodebuild test -scheme App -destination "id=$UDID" -only-testing:AppTests

The device name is an example; pick one the runner image lists. Warmbuild’s select-tests: true computes the -only-testing arguments per pull request from what the diff reaches; in a replay of 100 default-branch commits of one app, the median commit ran 34 of 505 unit tests (test selection).

7. Pick the runner by cost per job, not per minute

The M2 Pro runner costs 1.65 times the standard rate. A 20-minute job costs $1.24 on macos-26; on macos-26-xlarge it costs less only if it finishes in under about 12 minutes. Measure the same job on both before switching. Self-hosted Macs remove GitHub’s per-minute charge, but a Mac that runs pull requests from forks runs untrusted code, and someone has to keep Xcode and the Simulators current.

Where to start

1. Find where the minutes go: GitHub’s billing usage report per repository, and each job’s step timings.
2. Remove runs: levers 1 to 3 are a few lines of YAML each and have no downside for most teams.
3. Move work off macOS (lever 4).
4. Shorten what is left: compilation (lever 5), then tests (lever 6).
5. Re-measure, then decide on runner size (lever 7).