# GitHub Actions ran out of minutes

> GitHub Actions ran out of minutes? What stops, what keeps running, how to see where the allowance went, and four ways to stop hitting the wall.

Source: https://latchkey.dev/learn/cost/github-actions-out-of-minutes  
Updated: 2026-09-20

If GitHub Actions ran out of minutes on your account, whether anything stops depends on one setting: GitHub states that "If your account does not have a valid payment method on file, usage is blocked once you use up your quota", and with one on file the minutes simply begin billing instead. This page separates what stops from what keeps running, shows how to find where the allowance went, and gives four changes that stop the wall arriving every month.

Running out of minutes is a billing event, not a failure. Nothing is broken and no runner is down: the fix is a decision about money, not a change to your pipeline.

It is worth making deliberately, because the default is the one nobody chose: an account with no card on file stops private-repository jobs the moment the quota is gone, usually mid-release.

## Three things can happen, and you chose one of them

The included minutes in your plan cover standard GitHub-hosted runners on private repositories. When that quantity is used up for the cycle, GitHub reads two settings and takes one of three paths.

The first is a stop: without a valid payment method on file, "usage is blocked once you use up your quota". Jobs do not queue and wait for the reset, they refuse to start. The second is also a stop, but a deliberate one. A GitHub budget carries a switch: with "Stop usage when budget limit is reached" enabled, "additional usage is blocked".

The third is the quiet one: with a payment method and no stop-usage budget, you "will be notified by email if you exceed your budget, but usage will not be stopped", and the minutes bill at the runner's rate.

## What keeps running no matter what the allowance says

Several categories of work never touched the allowance, so they are unaffected when it is gone. Knowing which of your workflows are already in one tells you how much of your pipeline is at risk. The last item is the counterintuitive one: larger runners were never covered, so a 16-core job carries on billing at its own rate while the standard runners beside it are blocked.

- Public repositories: standard GitHub-hosted runners there are free and unlimited, so they never drew on the quota.
- Self-hosted runners: "GitHub Actions usage is free for self-hosted runners", so their minutes are not metered at all.
- Managed third-party runners: those jobs are billed by the vendor rather than metered by GitHub.
- Larger runners: "Included minutes cannot be used for larger runners", so they were already billing and keep billing.

> Quoted from [GitHub Actions billing](https://docs.github.com/en/billing/managing-billing-for-your-products/about-billing-for-github-actions) and [Actions runner pricing](https://docs.github.com/en/billing/reference/actions-runner-pricing), read 20 September 2026.

## Find out where the allowance went before you change anything

The billing dashboard gives you a total, which tells you that you are out and nothing else. The detailed usage report gives you lines. It covers at most 31 days, arrives by email rather than downloading in the browser, and is the only report that carries `workflow_path`.

Sort by `sku` first and `workflow_path` second. The first names the machine, and GitHub publishes no per-operating-system conversion for included minutes, so read the allowance as a minute count rather than as an amount of money. What is not in doubt is the rate past the allowance, which is where a macOS line and a Linux line separate. The second names the file to open.

Expect one or two workflows rather than a broad drift. In our experience it is a matrix that fans out on every push, a schedule on a repository nobody deploys, or a consumer nobody counted: Copilot code review has consumed plan minutes on private repositories since 1 June 2026.

## Way one: pick the ceiling instead of discovering it

Decide which of the three paths above you want, and set it. If a stop is right, leave the account without a card or set a budget with the stop-usage switch on. If a stop is not acceptable mid-release, add a payment method and a budget without the switch.

Either way, set the alerts. A budget can notify at 75, 90 and 100 percent of its limit, and since 3 March 2026 GitHub also emails you when included usage reaches 90 and 100 percent for Actions minutes and storage, opt-out rather than opt-in. The point is that 90 percent arrives with days left in the cycle.

## Way two: take the heaviest workflow off the meter

The allowance only counts standard GitHub-hosted runners on private repositories, so anything you move off that path stops consuming it. A self-hosted runner is not metered, and a managed runner is billed by its vendor rather than counted by GitHub.

That is a different lever from making the workflow cheaper, and it acts immediately: moving one heavy matrix off the meter buys back its share of the quota for the rest of the cycle. The trade is worth stating plainly, though, because self-hosting moves the cost to your cloud bill and your ops time, and a managed runner moves it to another invoice. [What a self-hosted GitHub runner really costs](/learn/cost/self-hosted-github-runner-total-cost) prices the first of those, and [how Latchkey cuts the GitHub Actions bill](/github-actions-cost-reduction) is the case for the second.

```.github/workflows/ci.yml
# Metered: a standard GitHub-hosted runner draws on your included minutes
jobs:
  test:
    runs-on: ubuntu-latest

# Not metered: neither of these touches the GitHub allowance
jobs:
  test:
    runs-on: [self-hosted, linux, x64]
  build:
    runs-on: latchkey-small
```

## Way three: stop the same work billing twice

A job that fails for a reason unrelated to your code still spends its minutes, and the re-run spends them again. GitHub capped the extreme case on 10 April 2026: "Actions workflows are now limited to 50 reruns", added "in response to some automations that attempt hundreds of retries on a given workflow". That stops a runaway, but not the ordinary case of a flaky suite re-run twice a day.

This is the part you can recover without deciding anything about money. [Flaky tests passing on retry](/learn/failures/flaky-tests-passing-on-retry-in-ci) and [exit code 137](/learn/failures/exit-code-137-in-github-actions) are the two failures that most often turn one job into three.

## Way four: shrink what the allowance has to cover

Once the ceiling is set and the re-runs are gone, the remaining lever is the work itself, usually the workflows nobody reads. A nightly job on a repository that stopped shipping spends the same minutes as one guarding production. Two checks pay for themselves: schedules on repositories with no recent merges, and workflows that run on forks, where a busy upstream project can spend an organization's allowance on pull requests it never merges.

Then rank the rest by what each change saves. [How to reduce GitHub Actions costs](/learn/cost/reduce-github-actions-costs) does that ranking on one worked month, and the ordering is not the one most tip lists give you.

```.github/workflows/nightly.yml
# before: a nightly run on every repository in the org, alive or not
on:
  schedule:
    - cron: '0 3 * * *'

# after: weekdays only, and never on a fork of this repository
on:
  schedule:
    - cron: '0 3 * * 1-5'
jobs:
  nightly:
    if: github.event.repository.fork == false
    runs-on: ubuntu-latest
```

## What the wall actually costs, in numbers

Put a figure on it. Because no per-operating-system conversion is published, this counts one minute of any runner as one minute of allowance. A team on GitHub Team burns its 3,000 included minutes by day 11 of a 30 day cycle: that pace is 272.7 minutes a day, so the cycle is about 8,182 minutes and the part past the allowance is 5,182.

On standard Linux runners at $0.006 that overage is $31.09. The same 5,182 minutes on macOS at $0.062 would be $321.28. So the wall is a $31 problem or a $321 problem depending on which runner your workflows asked for, which is why the `sku` column is the first thing to read.

For comparison, all 8,182 of those Linux minutes on a Latchkey small runner at $0.0025 are $20.46 of compute, plus a plan fee of $5, $19 or $49 a month, with Latchkey's own included minutes not netted off: $25.46, $39.46 or $69.46 all in, against GitHub's $31.09 overage with the 3,000 free minutes unused. Only the smallest plan wins at this volume. At 40,000 minutes it separates: $222 on GitHub against $105 to $149 all in, 33 to 53 percent lower.

## FAQ

### What happens when GitHub Actions minutes run out?

On private repositories, standard-runner jobs either start billing per minute or stop entirely. They stop if the account has no valid payment method, or if a budget with the stop-usage switch has been exhausted. Otherwise they bill at the runner's rate. Public repositories, self-hosted runners and larger runners are unaffected.

### Why does my job say the account has insufficient minutes?

Because the included minutes for the cycle are gone and GitHub has nothing to bill the overage to. It is the blocked state rather than an error in the workflow: the run never starts, so there are no step logs to read. Adding a valid payment method, or raising a budget that is capping you, lets the queued work start immediately.

### How do I raise my GitHub Actions spending limit?

Through a budget, set per product in your account, organization or enterprise billing settings. Create or edit the Actions budget, set a limit above zero, and decide whether to enable "Stop usage when budget limit is reached". Alerts can fire at 75, 90 and 100 percent of the limit so the cap is not a surprise.

### Can I keep running workflows on public repositories after the minutes run out?

Yes. Standard GitHub-hosted runners are free and unlimited on public repositories, so they never drew on the allowance and are not affected when it is exhausted. The one exception is a larger runner on a public repository, which is billed at its per-minute rate and needs a payment method whatever your allowance looks like.

## References

- [GitHub Actions billing: included minutes, and usage blocked without a payment method (verified 2026-09-20)](https://docs.github.com/en/billing/managing-billing-for-your-products/about-billing-for-github-actions)
- [GitHub: setting up budgets, alert thresholds and the stop-usage option (verified 2026-09-20)](https://docs.github.com/en/billing/tutorials/set-up-budgets)
- [GitHub: usage report types and the workflow_path column (verified 2026-09-20)](https://docs.github.com/en/billing/reference/usage-reports)
- [GitHub Changelog: Actions workflows are limited to 50 reruns, 10 April 2026 (verified 2026-09-20)](https://github.blog/changelog/2026-04-10-actions-workflows-are-limited-to-50-reruns)
- [Latchkey pricing: published per-minute runner rates and plan fees (verified 2026-09-20)](https://latchkey.dev/pricing)

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt