Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallAdd a workflow-level concurrency group with cancel-in-progress: true to request cancellation of an older run when a newer run enters the same group. Scope the group carefully: a collision can make different workflows or branches cancel one another. The setting can reduce execution spent on obsolete validation, but GitHub does not promise a fixed number of CI minutes saved; the result depends on your event rate, run duration, and when cancellation takes effect.
What concurrency cancellation does
GitHub Actions permits concurrent workflow runs and jobs by default. A concurrency group limits simultaneous work sharing a group name. With the default behavior, 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 in progress in that group. These are distinct behaviors: pending-run replacement happens without the setting, while the setting extends cancellation to the active run or job. See GitHub’s concurrency documentation.
As an Amazon Associate I earn from qualifying purchases.
This is useful when a later push makes an earlier test run irrelevant—for example, when a developer pushes several commits to a feature branch and only needs validation of the latest state. It is not a general-purpose duplicate-run detector: GitHub applies the configured group rules, not a judgment about whether two runs are logically redundant.
Configure a group for the same workflow and ref
For a common case—cancel older runs of the same workflow on the same branch or ref—add this at the workflow level:
#1 Best Overall
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: truegithub.workflow distinguishes workflows, while github.ref distinguishes refs. Together they help keep cancellation scoped to runs of the same workflow and ref. Group names are case-insensitive, so capitalization differences do not create separate groups. GitHub documents this pattern in its workflow syntax reference.
Choose the scope to match the work
- Same workflow and branch: A workflow/ref group is appropriate when only the newest validation on each branch matters.
- Across workflows: Avoid reusing the same group name unintentionally. Workflows that share a group can affect one another, even if their files or purposes differ.
- Pull request events:
github.head_refis useful for distinguishing pull request branches, but it is undefined for some event types. GitHub’s syntax reference shows a fallback such as${{ github.head_ref || github.run_id }}when a workflow handles events without a head ref. - Conditional cancellation: If only some refs should cancel active work—for example, non-release branches—GitHub supports making
cancel-in-progressan expression. Check the syntax reference for the expression pattern that fits your event and branch rules.
The right group is the boundary within which work is safe to supersede. Before adopting a group expression, list the events and refs that trigger the workflow, then check that any two runs in the same group really may replace or cancel one another.
Choose cancellation, replacement, or a queue
| Behavior | What happens | Best fit |
|---|---|---|
| Default concurrency behavior | One run or job executes at a time in a group; a newer pending run replaces the existing pending run. | Work where it is useful to keep only the latest waiting run, but an active run should not necessarily be canceled. |
cancel-in-progress: true |
Requests cancellation of the in-progress run or job as well as the normal pending-run replacement behavior. | Validation that becomes obsolete as soon as a newer commit enters the same group. |
queue: max |
Allows up to 100 pending runs. It cannot be combined with cancel-in-progress: true. |
Work that should wait rather than have earlier pending work replaced or active work canceled. |
The pending-run limit and incompatibility are documented in GitHub’s workflow syntax reference. Choose based on whether older work is disposable, whether pending work should be replaced or preserved in a queue, and whether order matters.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
When cancellation is a poor fit
Cancellation is risky when a run performs work whose partial completion has consequences. Review workflows that release software, deploy services, publish artifacts, migrate data, or modify external systems. If an operation must finish, or if successive operations must run in order, canceling its active run may leave the system in an undesired state. Use a queue or a narrower concurrency group when work needs serialization without discarding active work.
GitHub’s deployment guidance describes concurrency as a way to keep a maximum of one deployment in progress for an environment. That does not mean canceling every active deployment is automatically safe: the group and cancellation policy still need to preserve the deployment sequence you require. See Deploying with GitHub Actions.
- Use cancellation for repeatable checks whose earlier results are no longer useful after a newer commit.
- Prefer a queue when every run must complete, or when order is important.
- Keep deployments and other external side effects out of a broad cancel-in-progress group unless interruption is explicitly safe.
- Consider cleanup behavior before canceling; cancellation does not guarantee every cleanup job or step will stop immediately.
What happens after GitHub requests cancellation
Cancellation is not necessarily instantaneous. GitHub re-evaluates conditions on running jobs when cancellation begins. Jobs whose conditions remain true—including jobs using if: always()—are not canceled at that point. GitHub also re-evaluates unfinished steps. A cleanup job or step with a condition that remains true can therefore continue while the rest of a run is being canceled.
For steps marked for cancellation, the runner sends an interrupt signal to the step’s entry process. GitHub documents the sequence as sending SIGINT/Ctrl-C; if the process does not exit within 7,500 milliseconds, the runner sends a termination signal and waits another 2,500 milliseconds before killing the process tree. The server then allows a five-minute cancellation timeout period before forcibly terminating jobs and steps still marked for cancellation. These are cancellation timings, not estimates of CI time saved. Details are in the workflow cancellation reference.
If prompt runner release matters, avoid assuming that setting cancel-in-progress: true instantly frees a runner. Inspect job and step conditions, especially always(), and design cleanup for interruption or continuation as appropriate. To stop a run manually, GitHub also documents the workflow-run cancellation procedure.
Estimate the CI minutes your repository may avoid
GitHub’s documentation explains concurrency behavior and cancellation timing, but does not publish a typical minutes-saved figure for a repository or run. The savings depend on how often new work supersedes old work, how long those older runs have left, and how quickly cancellation reaches their jobs and steps.
To assess the effect in your repository, compare the billed or consumed minutes for runs that would have been canceled against the runs that replace them, over a representative period. Treat that as a repository-specific estimate rather than a guaranteed saving: runs may be canceled late, and work that continues under its conditions still consumes execution time.
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.
Recommended Free Tools
