Add a workflow-level concurrency group with cancel-in-progress: true to ask GitHub Actions to cancel an older run when a newer run in the same group starts. This is useful when a new push makes an earlier test run obsolete; it is not a guaranteed number of minutes saved. The result depends on how often runs overlap, how long they take, and how soon cancellation takes effect.
What concurrency cancellation does
GitHub Actions permits workflow runs and jobs to run concurrently by default. A concurrency group brings runs or jobs with the same group name under one concurrency policy. By default, GitHub keeps at most one pending run in a group; a newer pending run replaces the older pending run. Adding cancel-in-progress: true also requests cancellation of work already running in that group. GitHub’s concurrency overview and workflow syntax reference describe these behaviors.
![Computer Networking Bible: [3 in 1] The Complete Crash Course to Effectively Design, Implement and Manage Networks. Including Sections on Security, Performance and Scalability](https://m.media-amazon.com/images/I/41H4YJnxKgL._SL160_.jpg)
For example, if three commits are pushed while CI is busy, the default policy can discard an older queued run in favor of the newest one. With in-progress cancellation enabled, the active run in that group is also asked to stop. This suits validation whose result for an older commit no longer matters; it may not suit work that must finish or run in sequence.
Configure cancellation for the same workflow and ref
To cancel older runs of a workflow when a newer run targets the same branch or ref, put this at the workflow’s top level:
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errors#1 Best Overall
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: trueThe group combines the workflow identity and ref. That scope helps keep cancellation limited to runs of the same workflow on the same ref, rather than making unrelated workflows compete for one group. Group names are case-insensitive, so differences in capitalization do not create separate groups. See the workflow syntax reference for supported context expressions and examples.
Pull request events and fallback values
For some pull request events, github.head_ref is undefined. If your group expression uses that context, provide a fallback. GitHub’s syntax reference shows the pattern ${{ github.head_ref || github.run_id }}. Choose the fallback based on which events the workflow handles and which runs you intend to group; a unique run ID avoids grouping runs when the head ref is absent.
Limit cancellation to selected branches
cancel-in-progress can be an expression rather than a fixed Boolean. That lets a workflow cancel active work on ordinary branches while preserving runs on release branches, for example. Set the expression to match the repository’s branch naming and release policy, and verify the behavior against the workflow’s actual triggers. GitHub documents conditional cancellation in the syntax reference.
Choose a policy based on whether earlier work can be discarded
| Policy | What happens to pending work | What happens to active work | Best fit |
|---|---|---|---|
| Default concurrency behavior | One pending run is retained; a newer pending run replaces the previous one. | Not canceled just because a newer run is pending. | Keep the active run, but let only the latest waiting run proceed. |
cancel-in-progress: true |
A newer pending run replaces the prior pending run. | Cancellation is requested for active work in the group. | Superseded tests or checks that are safe to abandon. |
queue: max |
Up to 100 pending runs can wait. | Do not combine this option with cancel-in-progress: true. |
Work that should wait rather than be replaced or canceled. |
The 100-pending-run limit and the incompatibility between queue: max and cancel-in-progress: true are specified in GitHub’s workflow syntax reference. Use a queue when every run matters or ordering is important; use cancellation when newer work makes older work irrelevant.
Keep deployments and side-effecting work out of broad cancellation groups
Before enabling cancellation, identify whether the workflow performs a release, deployment, publication, migration, or another operation that changes an external system. A newer run can request cancellation of an active run in the same group, which may leave such work incomplete or interrupt an expected sequence. GitHub’s deployment guidance describes using concurrency to keep a maximum of one deployment in progress for an environment. That serialization goal is not the same as canceling every active deployment whenever a new one appears.
- Use a distinct, narrowly scoped group for work that must not collide with ordinary CI.
- Choose a waiting queue when deployments must be processed rather than discarded.
- Check whether cleanup steps, external side effects, or follow-up jobs depend on the run finishing.
Cancellation is not necessarily immediate
When GitHub starts cancellation, it re-evaluates conditions on running jobs. A job whose condition remains true—including a job using if: always()—is not canceled at that point. GitHub also re-evaluates unfinished steps. This means a workflow may continue running cleanup or other conditionally retained work after cancellation has been requested.
For steps marked for cancellation, GitHub says the runner sends an interrupt signal to the step’s entry process, then escalates if it does not exit. The runner waits 7,500 milliseconds before sending a termination signal, then waits another 2,500 milliseconds before killing the process tree. GitHub’s server has a five-minute cancellation timeout period before forcibly terminating jobs and steps still marked for cancellation. These are documented cancellation timings, not estimates of how many CI minutes a workflow will save. Details are in the workflow cancellation reference.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Estimate the benefit from your own runs
GitHub documents the concurrency mechanism, but its cited documentation does not provide a typical or guaranteed per-run minutes-saved figure. To estimate the effect in your repository, compare overlapping runs that become obsolete with how long they would otherwise have continued, accounting for how quickly cancellation and any retained cleanup work finish. The result will vary with event frequency, workflow duration, and timing; concurrency configuration alone does not establish a savings amount.
Best Value
- Used Book in Good Condition
To cancel a workflow manually rather than through concurrency, GitHub also documents the process in Canceling a workflow run.
Quick Recap
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.
