DEV Community: A.F.

Your GitHub Actions bill is mostly macOS minutes (here's how to tell)

A.F. — Mon, 06 Jul 2026 23:36:52 +0000

If your GitHub Actions bill surprises you, look at the macOS line first. A macOS runner minute bills at roughly ten times a Linux minute, and the xlarge tiers cost more still. One ten-minute macOS job is a hundred Linux-equivalent minutes. Run it on every PR and it is almost certainly the biggest single line on your bill.

The multipliers

Linux is the baseline (about $0.006/min on a standard 2-core runner in 2026).
Windows bills roughly 2x Linux.
macOS bills roughly 10x Linux, and the arm64 xlarge tiers bill above that.

The billing page shows minutes. It does not shout about the multiplier. Ten thousand macOS minutes and ten thousand Linux minutes look the same in a usage table and differ by an order of magnitude in dollars.

How serious projects end up here

Not by accident, exactly. By default-following. vscode's PR pipeline calls its darwin test workflow four times per pull request, each on runs-on: macos-14-xlarge. For an editor that ships a native macOS app, that is a defensible choice made by a team with a Microsoft-sized budget. The pattern to copy is the deliberateness, not the config: most repos running macOS jobs on every PR are not shipping macOS binaries. The job landed in a template years ago and nobody priced it since.

What actually needs macOS

Xcode builds, iOS/macOS app compilation, simulator tests
Code signing and notarization
Reproducing genuinely platform-specific bugs (filesystem case-insensitivity, BSD userland)

What doesn't: your unit tests, your linter, your web build "just to be safe." If the job would pass in a Linux container, it is paying a 10x premium for nothing.

The fixes, cheapest first

1. Move Linux-capable jobs off premium runners. Usually a one-line change:

jobs:
  test:
    runs-on: ubuntu-latest  # was macos-latest — ~10x cheaper

2. Gate macOS to where it earns its rate. Run it on the default branch or a release tag, not every PR commit:

jobs:
  macos-test:
    if: github.ref == 'refs/heads/main'   # PRs run the Linux leg only
    runs-on: macos-14

3. Trim the matrix. A full OS x version grid multiplies the premium legs with everything else. And set timeout-minutes everywhere it hurts most: a hung macOS job burns the 6-hour default at 10x the rate.

Find every premium-runner job you have

I built a free scanner for exactly this class of config waste: it flags every workflow using macOS or Windows runners, plus the other quiet defaults (missing timeouts, no concurrency group, uncached dependencies) with copy-paste fixes. Two minutes to find out which of your workflows are on the expensive tier: gitspider.com/scan

This is a syndicated version of the full guide, which also covers the free-plan macOS concurrency cap and per-stack examples.

The one-line GitHub Actions cache most repos forget

A.F. — Wed, 01 Jul 2026 16:56:00 +0000

The first thing I check on a slow CI run is the cache, and the cache is usually missing. It is the cheapest speedup there is: one line on your setup step, and every run stops re-downloading and rebuilding the exact dependencies it already had yesterday. On a typical Node or Python project that is 30 to 90 seconds back, every run, forever. People skip it anyway, then pay GitHub to reinstall lodash for the ten-thousandth time.

The free win: built-in caching

You probably do not need actions/cache directly. The setup-* actions cache your package manager for you, you just have to turn it on:

# Node
- uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: 'npm'        # or 'yarn' / 'pnpm'

# Python
- uses: actions/setup-python@v5
  with:
    python-version: '3.12'
    cache: 'pip'

Go (actions/setup-go) caches by default. Java (actions/setup-java) needs cache: 'gradle' (or 'maven') set explicitly. Check your setup step first, the one-line fix covers most projects.

Custom caching with actions/cache

For anything the setup actions do not cover (a build output, a tool the package manager does not own), reach for actions/cache with an explicit path and key:

- uses: actions/cache@v4
  with:
    path: ~/.cache/my-tool
    key: ${{ runner.os }}-mytool-${{ hashFiles('**/lockfile') }}
    restore-keys: |
      ${{ runner.os }}-mytool-

Get the key right, or the cache never helps

The key should change only when your dependencies change, which is why it hashes the lockfile (hashFiles('**/package-lock.json')). The restore-keys prefix lets a run fall back to the most recent matching cache when the exact key misses, so a single dependency bump restores most of the cache instead of rebuilding everything.

Why your cache "isn't working"

Caching the wrong directory: cache the package manager's store, not node_modules on most setups.
A key with no lockfile hash, so it never invalidates and you keep serving a stale cache.
Cache scope: a branch reads its own cache plus the default branch's, but not a sibling branch's, so cross-branch hits can surprise you.

Find out if you're missing it

astro, for instance, has a release workflow with no dependency cache. Curious about yours? See real scorecards on the showcase, then scan your own.

I build GitSpider, which scans a repo's GitHub Actions and flags the missing cache (and the rest) with the fix for each. Free, no install for public repos: gitspider.com/scan.

Cancel duplicate GitHub Actions runs with one block (and the one place you shouldn't)

A.F. — Wed, 01 Jul 2026 03:33:34 +0000

You push a fix, spot a typo a second later, and push again. GitHub cheerfully runs both. The first run, building a commit you've already replaced, grinds through your entire CI matrix while you sit waiting on the second. On a busy pull request that fans out to a dozen jobs, a real slice of your Actions minutes goes to building commits that were dead on arrival. The fix is one block of YAML, and it's the single most common thing missing from the repos I scan.

The one block

Drop this at the top level of a workflow file, alongside on: and jobs::

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

group buckets runs by workflow and branch. When a new run starts in a bucket that already has one going, cancel-in-progress: true kills the old one. Push twice and only the latest survives, instead of both running to the end.

What the group key actually does

github.ref is the branch (or, on a pull request, that PR's ref), so every branch and every PR gets its own bucket. Pushing to your PR cancels your previous run and touches nobody else's. Keeping github.workflow in the key stops separate workflows (CI vs lint vs docs) from cancelling each other.

One rule: never put github.sha or github.run_id in the group key. They are unique per commit and per run, so every run lands in its own bucket and nothing ever cancels. That's the number-one reason a concurrency block "isn't working." To make the key read as the branch name on pull requests (forks included), use ${{ github.workflow }}-${{ github.head_ref || github.ref }}.

Concurrency on a single job

The block can live on a job, not just the whole workflow, which is how you serialize one step (a deploy) while everything else still fans out:

jobs:
  deploy:
    runs-on: ubuntu-latest
    concurrency:
      group: deploy-${{ github.ref }}
      cancel-in-progress: false   # never two deploys at once
    steps:
      # ...

Top-level concurrency: governs the whole run; job-level governs that one job. Reach for job-level when only the deploy needs to be one-at-a-time and the tests can keep fanning out in parallel.

The one place you do NOT want cancel-in-progress

Deploy, release, and publish workflows. Cancelling a deploy halfway can leave a half-pushed image or a partially published package. For those you still want a concurrency group, so two never run at once, but with cancellation OFF, which queues them instead:

concurrency:
  group: deploy-${{ github.ref }}
  cancel-in-progress: false   # serialize deploys, never interrupt one

Same logic for your default branch: you usually want every commit to main built and deployed, not cancelled by the next merge. A common pattern cancels only on branches and PRs:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ github.ref != 'refs/heads/main' }}

Why it's worth the thirty seconds

A cancelled run is minutes you don't spend. On private repos and self-hosted runners that's a direct line on the bill; on a public repo it's still faster feedback and less queue contention, since a superseded run isn't tying up a runner your real build is waiting for. Three lines, the cheapest reliability win in Actions, and almost nobody sets it.

Common questions

Does it cancel matrix jobs too? Yes. A matrix run is still one workflow run, so a superseded run cancels every matrix leg at once, not one at a time.

Why isn't my concurrency cancelling anything? Almost always the group key is too unique, usually a github.sha or github.run_id that snuck in, so no two runs ever share a bucket. Or cancel-in-progress is missing (it defaults to false).

Can I queue runs instead of cancelling them? Yes, set cancel-in-progress: false. GitHub keeps one run going and at most one waiting, cancelling older pending runs but never the one in flight. That's the right mode for deploys and releases.

Find out if you're missing it

It's the most common gap I see, big repos included. prettier, for instance, has no concurrency group on its test workflow. See real 30-day Actions scorecards on the showcase, then scan your own.

I build GitSpider, which scans a repo's GitHub Actions and flags exactly which of these patterns apply, with the fix for each. Free, no install for public repos: gitspider.com/scan.

The GitHub Actions workflow that's been failing for weeks (and how to find yours)

A.F. — Mon, 29 Jun 2026 21:49:48 +0000

trpc has a scheduled workflow called "Lock Issues & PRs." Its own scorecard shows it failing on almost every run. It is still scheduled, still running, still red. trpc ships excellent software, which is exactly the point: if a project this careful has a workflow that has been red for ages, the rest of us almost certainly do too.

It is not a one-off. drizzle-orm has one ("Unpublish release"). cal.com has one ("PR Update"). I scanned 35 popular open-source repos and the same thing kept turning up: a scheduled workflow that fails on nearly every run, quietly, for a long time.

Why nobody notices

GitHub does email you when a scheduled workflow fails. So how do these survive? Two reasons.

First, those emails are routine. You get them for flaky reruns and transient blips too, so you filter them out. Second, a workflow that is always red stops reading as a signal. It is just how that row looks now.

I did exactly this on my own project. GitHub emailed me that a workflow had failed. The next day it emailed again. I saw it, told myself I would fix it tomorrow, and promptly forgot. It was my nightly database backup, quietly broken the whole time, and I only caught it when a failure-rate number crept up where I would notice.

An always-red workflow is not free

It burns minutes every run to produce nothing but a red X. Worse, it trains you to ignore the failure that actually matters: the day a real one lands in the same inbox you have learned to skim past.

How to find yours

Open your Actions tab and look at the scheduled workflows, the cron-triggered ones nobody watches. If the last several runs are all red, you found one. From the CLI:

gh run list --workflow="Lock Issues & PRs" --status=failure

What to do about it

Two honest options: fix it, or if the workflow is genuinely abandoned, turn it off. Do not leave it scheduled and red.

gh workflow disable "Lock Issues & PRs"

Or drop the schedule trigger from the workflow file if it should not run on a timer at all. A disabled workflow is honest. A red one you have trained yourself to ignore is a liability.

I built a free scanner that flags always-failing workflows (and other CI waste) for any public repo, no install required: gitspider.com/scan. The full writeup with the config fixes lives here.

6 reasons your GitHub Actions CI is slow, with the one-line fix for each

A.F. — Mon, 29 Jun 2026 21:49:26 +0000

Two days ago GitHub emailed me to say one of my workflows had failed. The next day it emailed me again. I saw it, told myself I'd fix it tomorrow, and promptly forgot. It was my nightly database backup, quietly broken the whole time, and I only caught it because a failure-rate number nudged up.

A failed run at least gets you an email. A slow run gets you nothing. GitHub never pings you when CI quietly takes twice as long, runs the whole suite twice per PR, or rebuilds dependencies from scratch every time. That waste compounds where no one looks. Here are the usual culprits, each with the exact fix.

When I scanned 35 popular open-source repos, not one had a fully clean config. 32 of 35 had no concurrency control, 33 of 35 had no job timeouts, and 22 of 35 ran the full suite twice on every PR. If projects this polished leave minutes on the table, the rest of us definitely do.

Your suite runs twice on every PR (push + pull_request)

Trigger a workflow on both push and pull_request and, for a branch in the same repo, opening a PR fires both. You just paid for two identical runs. This one is pure waste and it can roughly halve your PR-related minutes. Trigger on pull_request, and keep push for your default branch:

on:
  push:
    branches: [main]
  pull_request:

Old runs don't cancel when you push again (no concurrency group)

Push a fix 30 seconds after the first push and, with no concurrency group, both runs go to completion. The first is dead weight, and it is holding a slot in your queue while it finishes. This hides even when you do have a group: a concurrency block without cancel-in-progress queues the new run behind the old one instead of cancelling it, so the superseded run still finishes. Add a group keyed on the branch, with cancel-in-progress, so a new push supersedes the old run:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

Every run reinstalls dependencies from scratch (no cache)

No cache means every run re-downloads and rebuilds your dependencies. On a typical Node or Python project that is roughly 30 to 90 seconds per run, every run, forever. The setup-* actions cache for free, you just have to ask:

- uses: actions/setup-node@v4
  with:
    node-version: 20
    cache: 'npm'

Your matrix is bigger than it needs to be

Every OS times every version multiplies your minutes. Most regressions show up on a single combination, so run a slim matrix on PRs and save the full grid for your default branch or a nightly run:

strategy:
  matrix:
    os: [ubuntu-latest]   # add macos/windows only on main or nightly
    node: [20]

A README typo runs your whole test suite (no paths filter)

Without a paths filter, any change triggers full CI, docs-only commits included. Scope the trigger to the files that actually affect the build:

on:
  pull_request:
    paths:
      - 'src/**'
      - 'package.json'

A hung job can run for six hours (no timeout-minutes)

With no timeout-minutes, a stuck step runs until GitHub's 6-hour ceiling. One wedged run can quietly eat a day of minutes. Cap every job:

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 15

How to find which ones you have

Curious how the big projects do it? The showcase has real 30-day Actions scorecards for popular repos. Then point GitSpider at your own.

I build GitSpider, which scans a repo's GitHub Actions and flags exactly which of these apply, with the fix for each. Free, no install for public repos: gitspider.com/scan.

I scanned 35 popular repos' GitHub Actions. Here's what's broken.

A.F. — Sun, 28 Jun 2026 05:59:20 +0000

The 2026 pricing changes got me curious how the projects I actually use run their CI. So I scanned 35 well-known open-source repos (vite, next.js, prisma, astro, eslint, the usual suspects) and pulled their public GitHub Actions data: recent runs, config patterns, failure rates.

A few things genuinely surprised me.

Some workflows have been failing nearly every run. And nobody turned them off.

The one I didn't expect: trpc has a scheduled workflow ("Lock Issues & PRs") that's failing nearly every run, and it's still on. Its own scorecard flags it outright: "failing almost every run." (see it: https://gitspider.com/scan/trpc/trpc)

It wasn't alone. drizzle-orm and cal.com each have a workflow stuck in the same red-forever state.

This isn't a knock on those teams (they ship great software). It's how universal the "set a scheduled workflow and never look at it again" pattern is. If projects this good have one that's been red for months, most of us do too.

Premium runners are the norm, not the exception.

20 of the 35 run at least some CI on macOS or Windows, which bill ~10x and ~2x a Linux minute. Free on public repos, but if you're private and on macOS, your bill is a different universe from the Linux-only projects.

Not one of the 35 had a clean config

Every single repo had at least one fixable finding. Most common across all 35:

missing job timeout: 33/35
no paths filters: 32/35
no concurrency cancel: 32/35
push + pull_request both running the full suite: 22/35

None of these are hard to fix. They're just spread across dozens of workflow files, so nobody ever sits down and does it.

Reliability varies more than I'd have guessed

Failure rates ran from near-zero up to about a third of recent runs: solid ~34%, trpc ~32%, drizzle ~23%. Some is flaky tests, some is those always-red workflows dragging the average.

Caveats so this is honest: these are public repos, so Actions is free for them. The dollar figures (on the scorecards) are "what it would cost at paid rates," not their bill. And the scanner samples recent runs (capped at 500), so the counts are a sample, not a 30-day total.

I built the scanner (it's free, no install for public repos). The scorecards are here: https://gitspider.com/showcase?ref=devto , and you can scan your own at https://gitspider.com/scan?ref=devto . Honestly the most useful thing is just checking your own repo for that one workflow that's been red for months.