Skip to content
compiler.dev
Start free

Job Not Started: Recent Account Payments Have Failed

Last updated

The job was not started because recent account payments have failed or your spending limit needs to be increased means GitHub refused to start your Actions job for a billing reason: a failed payment, a missing payment method, or a budget that blocks further spending. Nothing is wrong with your workflow file. Fix the billing state, then re-run the job. Facts here come from GitHub's Actions billing docs, checked October 2026.

The exact message

The job was not started because recent account payments have failed or your spending limit needs to be increased.

It appears as an annotation on the run, and the job fails within a second or two without any steps running. GitHub may append a pointer to your billing settings, and the menu names change over time, but the meaning stays the same. GitHub's billing page does not document this exact message, so the causes below combine its billing rules with what the message says.

What triggers it

GitHub's docs describe the rules this way:

  • Each plan includes monthly minutes for private repositories: 2,000 on Free, 3,000 on Pro and Team, 50,000 on Enterprise Cloud.
  • Standard GitHub-hosted runners are free for public repositories. Larger runners are always charged.
  • If the account has no valid payment method, usage is blocked once the included quota is used up. Larger runners stay blocked until a payment method is added.
  • If the account has a payment method, spending can still be capped by budgets. When a budget is reached, jobs stop starting.

Causes, most likely first

1. Included minutes are used up and there is no payment method

Common on personal accounts and small orgs. Fix: add a card, and set a budget you are comfortable with.

2. A budget (spending limit) is set too low

A budget of $0 with "stop usage" turned on blocks all paid usage once the included minutes are gone. Raise the Actions budget, or create one if none exists.

3. The last payment failed

An expired card, a bank decline or a failed 3-D Secure check marks the account as delinquent. GitHub blocks paid usage until the payment goes through. Update the card and retry the payment from the billing page.

4. You are using larger runners without a payment method

Larger runners are never included in free minutes, so they need a valid payment method from the first minute.

5. The wrong account is billed

For an organisation, the bill goes to the organisation (or its enterprise), not to your personal account. Fixing your personal card will not help. Ask an organisation owner or billing manager to check the billing settings.

6. Invoiced accounts

If the account pays by invoice, an unpaid invoice may also block usage. Contact GitHub Support or your account manager.

How to fix it step by step

  1. Open the organisation or user settings, then the billing section, and find the payment method and the Actions usage.
  2. If a payment failed, update the card and retry the payment.
  3. Open the budgets page and check the Actions budget. Raise it, or turn off the stop-usage option if you accept the risk of a larger bill.
  4. Re-run the failed jobs. A job that was not started does not need a code change.
  5. Turn on email alerts for 90% and 100% of included usage so it does not surprise you again.

If you cannot access billing, ask someone with the owner or billing manager role.

Check how much you actually use

Minutes multiply quickly: a 10-minute job on 6 matrix cells is 60 minutes per push. Use the GitHub Actions cost calculator and the guide to GitHub Actions pricing to see where it goes, and reduce your Actions bill for ways to cut it.

Keep CI running while billing is sorted out

If you need builds to run right now, a self-hosted runner does not use GitHub's hosted minutes, so billing blocks on hosted usage do not apply to those jobs. compiler.dev is one way to do this without managing machines: install the GitHub App and change one line to runs-on: [self-hosted, Linux, compiler-ci]. It offers 200 free trial minutes (card required, nothing charged until used), then prepaid credit, and if its credit runs out the jobs fall back to your original runners. See pricing. Note that fallback to a GitHub-hosted runner is still subject to the billing block above.

How to prevent it

  1. Keep a valid payment method on the account that pays for Actions.
  2. Set a budget with an alert instead of a hard $0 limit, and review it monthly.
  3. Cancel stale runs and stop jobs from running on every push (see concurrency in The operation was canceled).
  4. Use caching and sharding to reduce minutes (speed up GitHub Actions).
  5. Track usage per repository in the Actions usage report.

If instead your job stays queued with no failure, see Waiting for a runner to pick up this job.

FAQ

Why did the job fail instantly without running any steps?

GitHub checked billing before starting the runner and refused. The job never reached a machine.

Do public repositories hit this error?

Standard runners are free for public repositories, so it is rare there. It can happen with larger runners, which are always charged.

Do I lose my workflow runs?

No. Fix billing and re-run the jobs from the Actions tab.

I added a card but it still fails. Why?

The card may have been added to your personal account while an organisation pays. Or a budget still blocks usage. Check both.

Related