"The job was not started because recent account payments have failed or your spending limit needs to be increased": what it means and how to fix it

GitHub shows this message when your account can't pay for more GitHub-hosted runner time. Either a budget with Stop usage when budget limit is reached has run out, or the plan's included compute is used up and there's no valid payment method behind it, or a payment failed. An organization owner fixes the budget in Billing & Licensing → Budgets and alerts, an owner or a billing manager fixes the payment in Billing & Licensing → Payment information, and the refused jobs run once you re-run them.

What the message means

Every GitHub plan includes a monthly amount of compute for GitHub-hosted runners, written in dollars, not minutes:

Each job's minutes are priced at its runner's rate (Linux 2-core, the runner behind ubuntu-latest on private repositories, is $0.006 a minute) and taken from that amount. Once it's gone, GitHub bills more use to your payment method, unless something stops it. This message is that stop.

What it covers:

• GitHub-hosted runners on private repositories. These draw on the included compute.
• Larger runners on any repository. GitHub bills them on public repositories too, and they require a valid payment method.
• Not standard runners on public repositories, and not self-hosted runners. GitHub lists both as usage that "remains free" and doesn't reduce the included compute.

The causes, and who can fix each

A budget set to stop usage

Budgets are monthly dollar amounts, and with Stop usage when budget limit is reached selected, any spent one that covers Actions blocks more use. Which budget it is, who can raise it, and what a $0 budget does are in the guide to "an Actions budget is preventing further use".

The $0 default and a missing payment method

Before budgets, GitHub controlled Actions overages with a "spending limit", and its documentation said: "If you are a monthly-billed customer, your account will have a default spending limit of 0 US dollars (USD), which prevents additional usage of minutes or storage for private repositories beyond the amounts included with your account." That page now redirects to the budgets guide. An account whose Actions budget is still $0 with the stop option on behaves the same way: it stops at the included compute.

Today's rule for accounts with no card is just as strict: "If your account does not have a valid payment method on file, usage is blocked once you use up your quota." And, in GitHub's words, "Larger runners require a valid payment method."

A failed payment

When GitHub can't charge your card, it emails you why and tries again a few days later. Until a payment goes through, "your account's paid features are locked." For personal accounts, GitHub adds that a failed authorization hold, when you sign up for Copilot or raise a budget, "can also lock your personal account billing and block GitHub Actions", even if you plan to stay on GitHub Free.

Fix it, step by step

Raise or loosen the budget (organization owner)

1. Click your profile picture, then Your organizations, then Settings next to the organization.
2. In the sidebar, under Access, click Billing & Licensing.
3. Click Budgets and alerts. Each row shows the budget's scope, what it has spent against its amount, and its status.
4. Find every budget that covers Actions: the product-level Actions budget, any SKU-level budget (a runner size), and any repository-scoped one.
5. Click the … menu next to the exhausted budget, then Edit. Raise the amount, or clear Stop usage when budget limit is reached if you'd rather get alerts than blocked jobs.
6. Re-run the refused jobs: open the workflow run, click Re-run jobs, then Re-run failed jobs.

On a personal account, start at github.com/settings/billing and click Budgets and alerts. For an organization in an enterprise, the enterprise's Billing & Licensing tab lists the enterprise and cost center budgets.

Many answers in GitHub's community forum still say "Settings → Billing & plans → Actions spending limit". That's the old billing screen. Today the control is the budget.

Fix a failed payment (owner or billing manager)

1. Open Billing & Licensing for the account, then Payment information.
2. Under Payment method, click Edit and enter a working card, or PayPal.
3. GitHub charges it right away. "The account will automatically unlock when a payment has been successfully processed. Payments may take up to 24 hours to process."
4. Check Payment history to see that the charge went through, then re-run the refused jobs.

If the bank declines again, call it with the amount, your billing date and the transaction ID from your receipt, and the merchant name, GitHub. Some banks outside the US restrict international, online or recurring card payments; ask yours to allow GitHub's.

When everything looks right

Two GitHub community threads show where the settings stop and Support starts:

• In #166876, an organization set an Actions budget above $0, confirmed no failed payments or open invoices, and kept getting this exact message. A support ticket fixed it: "after manually syncing, everything is working perfectly now."
• In #184661, Actions was disabled at the account level after heavy CI use. GitHub Support removed the flag once contacted.

Open a ticket at support.github.com with the message, a screenshot of Budgets and alerts, and your Payment history.

Why it tends to hit late in the month

For metered products such as Actions, GitHub's billing period starts at 00:00:00 UTC on the first of the month and ends at 23:59:59 UTC on its last day. The included compute resets at the start, and budgets count monthly.

So every job adds to one running total: first the included compute, then the budget. A team that runs at a steady pace crosses the line late in the month. A release week or a flaky test that retries brings it earlier. The block then holds until the 1st, 00:00 UTC, unless someone raises the budget.

One more trap: a new budget counts only usage from the day you create it. In its first month you can spend past it, even with the stop option on.

How to stop it happening again

Raise the budget and turn on alerts

Set the Actions budget to what a busy month really costs, and on the same page select Receive budget threshold alerts: GitHub emails you and shows a banner at 75%, 90% and 100%. Under Included usage alerts, select Receive alerts when my included usage reaches 90% and 100% to hear before billing starts. Add the person who can approve more spend as a billing contact in Additional billing details.

Keep one hard budget for Actions. A product budget next to a SKU budget, or an organization budget next to a repository budget, blocks jobs you didn't expect.

Spend fewer billable minutes

• Merge tiny jobs. GitHub rounds each job up to the next whole minute, so 30 jobs of 10 seconds bill 30 minutes.
• Use the smallest runner that works. Linux 2-core costs $0.006 a minute, Linux 4-core $0.012, and macOS $0.062, more than 10 times Linux 2-core.
• Stop paying for runs nobody reads. concurrency with cancel-in-progress: true cancels a run when a newer commit arrives, paths filters skip workflows a change doesn't touch, and timeout-minutes ends a hung job before the 6-hour limit.

Move jobs to runners with a fixed monthly price

GitHub doesn't bill self-hosted runners, and their minutes don't draw on your included compute. A job you move to one can't run your Actions budget out, and the budget can't stop it.

You can run self-hosted runners on your own machines and maintain them yourself, or rent them from a service. With a per-minute service, a busy month still costs more. With a fixed monthly price, it doesn't: when more jobs arrive than the plan runs at once, the extra ones wait in a queue instead of being blocked. GitHub cancels a self-hosted job that has waited 24 hours, so a queue can't hold one forever.

Skipbox works this way. It runs jobs from the private repositories of a GitHub organization or a personal account, each in a fresh Linux VM in Finland or Germany (EU), for $39, $79, or $149 a month with unlimited minutes and no usage charges. Your plan sets how many jobs run at once and how large each can be. Extra jobs wait their turn, and the bill stays the same. You move a job by changing its runs-on line, and move it back the same way. macOS, Windows, Arm and public-repository jobs stay on GitHub.

You can try it on your own jobs first: free for 7 days or 3,000 minutes, no card.

Sources

All read on 2026-11-09.

• GitHub Docs, Budgets and alerts: stopping usage for metered products, who can set budgets, 75/90/100% alerts, included usage alerts, the first billing cycle after creating a budget.
• GitHub Docs, Setting up budgets to control spending on metered products (where the old spending-limit page, managing your spending limit for GitHub Actions, now redirects): overlapping budgets and the $50 example, the stop option, the steps.
• GitHub Docs, the spending-limit page as archived on 2024-06-01 (Wayback Machine): the $0 default for monthly-billed customers.
• GitHub Docs, GitHub Actions billing: included compute by plan, what remains free, blocking without a payment method.
• GitHub Docs, Actions runner pricing: per-minute rates, rounding up to whole minutes.
• GitHub Docs, Billing cycles: the metered billing period in UTC.
• GitHub Docs, Troubleshooting a declined credit card charge, Unlocking a locked account, Managing your payment and billing information, Adding a billing manager to your organization.
• GitHub Docs, Actions limits: the 24-hour queue limit for self-hosted runners, the 6-hour job limit on GitHub-hosted runners.
• GitHub Community, #166876 "GitHub Action Failing Despite Adding Budget Amount" and #184661 "GitHub Actions disabled after heavy CI/CD usage".

Updated November 9, 2026