Cut CI queue time in GitHub Actions

Jobs start within seconds of being triggered. Queue time is measured honestly, from the run's trigger (created_at) to the job's started_at, not the job's own created_at, which GitHub stamps late for gated jobs and which hides the real wait. Concurrency groups are scoped so unrelated PRs don't share one lane, and there's enough available job concurrency that a burst of open PRs doesn't leave jobs waiting for a free slot.12

# Scope concurrency to the WORKFLOW and the ref, so each PR gets its own lane
# and this workflow never cancels a different workflow's runs.
#
# github.workflow is not optional here. Concurrency group names are repository-wide:
# GitHub cancels "any previously in-progress or pending job ... regardless of the
# workflow" that shares a group name. Leave it out and two workflows on the same ref
# cancel each other, which is a worse failure than the queueing you came here to fix.
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  queue: single
  # cancel superseded PR runs; let main / release runs finish
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

# If this workflow must keep a backlog instead of dropping pending runs, use this
# block INSTEAD. queue: max allows up to 100 pending runs, but GitHub rejects it
# when cancel-in-progress is true.
# concurrency:
#   group: ${{ github.workflow }}-${{ github.ref }}
#   queue: max
#   cancel-in-progress: false

Every PR queues behind one shared lane, so developers wait before a single step runs.

concurrency:
  group: ci        # every PR shares one lane, so they queue behind each other
  queue: single    # default: one pending run, then newer runs replace it

Queue time is wait the developer feels but no code change can fix, the job hasn't even started. The biggest structural cause on GitHub-hosted runners is the account-level concurrency cap: GitHub limits how many jobs you can run at once (around 20 on the Free plan as of this writing, more on paid tiers; the exact caps change, so treat the numbers as a snapshot and check GitHub's linked limits doc), so once your open PRs fan out past that ceiling, the extra jobs sit queued until a slot frees, no matter how well your own concurrency: groups are scoped. What you can fix in YAML is a group that serializes unrelated work. By default that group uses queue: single: one run or job is active, one pending run is retained, and the next arrival replaces the pending one. queue: max keeps a backlog of up to 100 pending runs instead, but GitHub rejects it if cancel-in-progress: true is also set. Measuring gated jobs honestly (from the run trigger, not the job's own timestamp) keeps those modes from hiding minutes of wait. The account cap itself you can't out-configure, which is why teams hitting it move to runners with more available concurrency; see StarSling vs GitHub Actions for how the two compare on wait-to-start.

Hand this prompt to your coding agent (Claude Code, Cursor, and the like) to audit and fix this practice in your own repo.

Inspect this repo's .github/workflows for `concurrency` groups that could be serializing unrelated work and making jobs wait before any step runs. Flag any group keyed on a global constant (for example `group: ci`) rather than the ref, and rescope it to `${{ github.workflow }}-${{ github.ref }}` so each PR gets its own lane instead of queuing behind the others. Include `${{ github.workflow }}`: concurrency group names are repository-wide, so a group keyed on the ref alone will cancel in-progress runs of OTHER workflows on that same ref. Keep in mind that queue time is the wait before a job starts, distinct from a slow-running job, so if jobs already start promptly the fix is elsewhere (caching, sharding), not concurrency. If the groups are already per-ref and jobs still wait before starting, the likely cause is GitHub's account-level concurrent-jobs cap, which is a capacity/provider decision, not a YAML change, so say so rather than inventing a workflow edit. Show me the diff and open a PR rather than applying it blindly.

Ground these changes in the upstream docs before you edit: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax, https://docs.github.com/en/actions/reference/limits. If you cannot fetch them, say so rather than guessing, and cite what you used in the PR description.

If you do not know why a run is slow yet, start with the diagnostic guide. Let an agent find which of these applies: /ci-speedup. If your workflows are already optimized but still slow, see our guide to fast GitHub Actions and GitHub Actions runner alternatives. Building containers in CI? The Docker workflow guide covers layer caching end to end. Want to see how your configuration measures up before changing anything? CI Score grades workflow config against a pass/fail rubric of these practices. It is not a speed measurement. To find exploitable workflow paths before attackers do, ci-secure checks the ten critical GitHub Actions attack vectors and lets you choose which fixes to apply.

• GitHub Actions too slow
• Fast GitHub Actions
• GitHub Actions alternatives
• GitHub Actions pricing
• Self-hosted GitHub Actions runners
• Docker CI on GitHub Actions
• Install the free /ci-score skill to improve your GitHub Actions setup
• Install the /ci-secure skill to close critical attack vectors in GitHub Actions
• Browse GitHub Actions agent skills