Recommended Free Tools
To cancel an older GitHub Actions run when a newer run for the same work arrives, add a concurrency group and set cancel-in-progress: true. The group key determines which runs compete, so include the workflow, branch, or pull request identity that matches what you consider redundant.
Configure cancellation for a workflow
Put concurrency at the top level of the workflow to control whole workflow runs. This GitHub-documented pattern groups runs by workflow and ref, so a newer run for that same workflow and ref can cancel the active one:
As an Amazon Associate I earn from qualifying purchases.
name: CI
on:
push:
branches: [main]
pull_request:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: ./run-tests.shSee GitHub’s concurrency documentation for supported syntax and behavior. If only one job should be constrained while the rest of the workflow continues, define concurrency under jobs.<job_id> instead.
Choose a group key that matches the work
Runs with the same group compete even if they come from different workflow files. A fixed group such as ci can therefore cause unrelated workflows in the repository to cancel or replace one another. Group names are case-insensitive. Include workflow identity when workflows should be isolated, and add a ref or pull request identifier when separate branches or PRs need independent runs. GitHub documents these group interactions in its concurrency guide.
Group by workflow and ref
${{ github.workflow }}-${{ github.ref }} separates workflows and refs. It is a suitable default when a newer run for the same workflow on the same ref makes the previous run stale.
Group pull requests by their head branch
For pull request events, github.ref can identify the PR merge ref. If you instead want a group based on the PR’s source branch, use github.head_ref. When the workflow also handles events where github.head_ref is unavailable, give the expression a fallback, for example:
concurrency:
group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
cancel-in-progress: trueThe run ID fallback keeps events without a head branch from sharing an empty group. Choose the key according to whether you want cancellation per workflow, ref, pull request, or another shared resource.
Understand what GitHub cancels
Without cancel-in-progress: true, concurrency still limits a group to one running workflow or job. A newer run replaces the group’s existing pending run by default, but the active run continues. With cancel-in-progress: true, a new run entering that group can also cancel the run already in progress. The setting may be an expression if cancellation should vary by event or branch; for example, GitHub documents excluding release branches.
Cancellation fits work whose result becomes obsolete, such as tests for an earlier commit after a newer commit is pushed. It may be unsuitable for deployments, migrations, releases, or other operations where every run has an effect that must finish.
Use queueing when every run must execute
If older work must wait and complete rather than be superseded, GitHub supports queue: max. It permits up to 100 pending workflow runs or jobs in a concurrency group, according to GitHub’s Actions limits documentation (checked October 4, 2026; GitHub notes limits can change). Do not combine it with cancel-in-progress: true: GitHub says that combination causes a workflow validation error. See the concurrency guide for configuration details.
Queueing does not guarantee strict FIFO dispatch. GitHub says ordering is based on when runs start waiting and is not guaranteed, so do not rely on it to preserve exact start order.
Pick the scope and behavior deliberately
| Decision | Use this when |
|---|---|
| Workflow-level concurrency | The whole workflow run should be grouped, queued, or canceled. |
| Job-level concurrency | Only one job should be constrained; other jobs in the workflow can continue. |
cancel-in-progress: true |
Newer work makes the active run obsolete. |
queue: max |
Each run must execute rather than be canceled; up to 100 runs can be pending per group under the documented limit. |
Set the group key to define the cancellation boundary. A broad shared key can affect unrelated workflows; a key that includes workflow and ref identity keeps competing runs closer to the intended unit of work. Neither cancellation nor queueing should be treated as a guarantee of exact execution order.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
