Cancel superseded runs with concurrency and cancel-in-progress

PR workflows declare a top-level concurrency group keyed on the workflow and ref, with cancel-in-progress set. Here is what the key actually does. It defaults to false: the run already in progress finishes, and the new run sits as pending until it does. Set it to true and the in-progress run in that group is cancelled immediately, so the new commit starts right away. That is what you want on a PR, where the superseded run is testing a commit no one is waiting on, and what you do not want on main or a release workflow, where every commit's run may deploy or publish and must complete. Scoping the value to the event (rather than a bare true) gives you both. The group itself is broad enough (per-workflow-per-ref) that it doesn't serialize unrelated jobs.12

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  # Cancel superseded runs on PRs; let main / release runs finish.
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

# On a workflow that ONLY runs on pull_request, the plain literal is fine:
#
#   concurrency:
#     group: ${{ github.workflow }}-${{ github.ref }}
#     cancel-in-progress: true
#
# The default is cancel-in-progress: false, which lets the in-progress run
# finish while the new run waits as pending. Never set the literal true on a
# workflow that also runs on push to main or on a release tag.

Each new push leaves the old run going, so obsolete commits keep occupying runners.

# No concurrency block. Every push to a PR starts another full run,
# and the superseded ones keep occupying runners until they finish.

Grafana, Moby, and Next.js use concurrency groups so stale pushes stop burning runner time after a newer run supersedes them.

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  # Cancel stale PR runs without interrupting push, tag, scheduled, or
  # manually dispatched validation.
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

concurrency:
  # Limit concurrent runs to 1 per PR, but allow concurrent runs on canary branch
  group: ${{ github.event_name == 'pull_request' && format('{0}-{1}', github.workflow, github.event.pull_request.number) || format('{0}-{1}-{2}', github.workflow, github.ref_name, github.run_id) }}
  cancel-in-progress: ${{ github.event_name == 'pull_request' }}

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ startsWith(github.ref, 'refs/pull/') }}

If your run log says Canceling since a higher priority waiting request for followed by your concurrency group and the word exists, that is this feature working: a newer push superseded the run. If it does not say that, you have the opposite problem. Without a concurrency group, rapid pushes to a PR leave several full runs racing, every obsolete one still burning a runner until it ends. Cancelling superseded runs reclaims that compute and frees capacity for runs that matter. Keep the group scoped to the ref, not a global constant, an over-narrow or over-broad group is its own problem (it can serialize or cancel jobs you didn't mean to).

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 a top-level `concurrency:` block on `pull_request` and `push` workflows. Flag any that have none, or one with `cancel-in-progress: false`, so obsolete runs pile up on rapid pushes. Add a `concurrency` group keyed on `${{ github.workflow }}-${{ github.ref }}` with `cancel-in-progress` scoped to PRs, and make sure the default branch and release workflows still let every run finish (never set `cancel-in-progress: true` on `main`). Confirm the group includes `github.ref` so it does not serialize unrelated PRs into one lane. 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/concepts/workflows-and-actions/concurrency. 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