GitHub Actions "The job was not started because your account has insufficient minutes"

By Daniel Zoghalchali·Latchkey

GitHub-hosted runners draw from a monthly included-minutes allowance scaled by your plan. When the allowance and any paid overage cap are exhausted, GitHub refuses to start the job instead of queuing it.

What this error means

Jobs on GitHub-hosted runners never start; the run shows the job failed immediately with a minutes message.

The job was not started because your account has insufficient minutes.
Add a payment method or increase your spending limit to continue using GitHub Actions.

Diagnose it: is the job queued, or is the runner gone?

A job that never starts and a job whose runner disappeared mid-run look similar in the UI and have opposite causes. The first is a labelling or capacity problem, the second is the runner being killed, usually by memory pressure or a spot reclaim.

- name: Runner facts
  run: |
    echo "runner name: $RUNNER_NAME"
    echo "os/arch:     $RUNNER_OS/$RUNNER_ARCH"
    nproc; free -h; df -h /
    echo "labels this job asked for: ${{ toJSON(job) }}"

Common causes

Monthly included minutes consumed

Free and paid plans include a fixed number of minutes per cycle; private-repo jobs on macOS/Windows multiply consumption (10x/2x).

No payment method or spending limit of $0

Without a payment method or with the Actions spending limit set to $0, GitHub cannot bill overage so jobs are blocked once included minutes run out.

Expensive runner OS multiplier

macOS jobs consume 10x and Windows 2x of wall-clock minutes, draining the allowance far faster than Linux.

How to fix it

Raise the Actions spending limit or add a payment method

1. Open Settings > Billing and plans > Spending limits (org or personal account).
2. Add a payment method if none exists.
3. Set an Actions spending limit above $0 (or unlimited) so overage minutes can bill.
4. Re-run the failed jobs.

Reduce minute consumption

1. Move jobs from macOS/Windows to Linux where possible (1x multiplier).
2. Add concurrency and path filters so fewer redundant runs start.
3. Cache dependencies to shorten job duration.

Use managed runners without GitHub minute caps

1. Latchkey managed runners bill your own compute and are not subject to GitHub-hosted included-minute caps.
2. Point runs-on at the Latchkey runner label so jobs stop competing for the GitHub allowance.

jobs:
  build:
    runs-on: latchkey-small

The failures that are not your workflow

• Exit 137 is the kernel out-of-memory killer, not an application error. Check free -h above against your peak usage.
• Disk exhaustion presents as unrelated write errors deep in a build. GitHub-hosted runners ship roughly 14 GB of free space, which a Docker-heavy job can exhaust.
• A lost connection to the server on a self-hosted runner is usually the host being reclaimed or rebooted, not a network fault in your job.
• A job that starts and immediately fails with no step output normally failed during runner setup, before your workflow ran at all.

How to prevent it

• Monitor minute usage in the billing dashboard before the cycle ends.
• Prefer Linux runners and cache aggressively to stretch the allowance.

Frequently asked questions

Related guides

References

• GitHub Actions documentation
• Workflow syntax for GitHub Actions