GitHub Actions concurrency limit reached for repository

By Daniel Zoghalchali·Latchkey

Each plan caps how many GitHub-hosted jobs can run at once. Beyond the cap, additional jobs queue until a slot frees, even if minutes remain. This is a parallelism cap, not a billing block.

What this error means

Many jobs sit queued while a few run; the limit is the plan concurrency cap, not minutes.

The job is queued because the concurrency limit for this account has been reached.
Waiting for a concurrent job slot to free up.

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

Plan concurrent-jobs cap hit

Total simultaneous GitHub-hosted jobs across the account reached the plan ceiling.

Large matrix fan-out

A big matrix requests more parallel jobs than the cap allows.

How to fix it

Reduce parallel demand or raise the plan

1. Cap matrix parallelism with strategy.max-parallel.
2. Upgrade the plan for a higher concurrency ceiling.

Use managed runners for elastic parallelism

1. Latchkey managed runners scale from warm pools without the GitHub-hosted shared concurrency cap, so burst jobs do not starve.
2. Target the Latchkey label for high-parallelism workloads.

jobs:
  test:
    runs-on: latchkey-small
    strategy:
      matrix:
        shard: [1,2,3,4,5,6,7,8]

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

• Right-size matrix fan-out to the available concurrency.
• Use managed runners when parallelism needs exceed the hosted cap.

Frequently asked questions

Related guides

References

• GitHub Actions documentation
• Workflow syntax for GitHub Actions