The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →GitHub Actions usually cancels a run because it shares a concurrency group with other work—not because it has chosen arbitrarily. Compare the group keys and cancellation settings for the affected workflow runs. By default, a new run replaces the existing pending run in the same group; it cancels a run that is already running only when cancel-in-progress is enabled. The fix is to make the group intentionally shared or distinct, then choose whether matching work should replace, wait, or proceed independently.
Why a different run gets canceled
A concurrency group is the scope in which GitHub Actions coordinates workflow runs or jobs that use the same group key. Group names are case-insensitive, and groups can be shared across workflows in the same repository. So a generic key such as ci, or a key based only on a branch name, may make unrelated workflows match.
There are two different cancellation cases to check:
- Pending run replaced: With the default
queue: singlebehavior, a group can have one pending run. When new work enters that group, it cancels and replaces the previous pending run. - Running work canceled: A newer matching run can cancel work that is already running when its concurrency configuration sets
cancel-in-progress: true.
GitHub describes the default pending behavior this way: “By default, any existing pending job or workflow in the same concurrency group will be canceled and the new queued job or workflow will take its place.” See GitHub’s concurrency documentation.
#1 Best Overall
To find the cause, inspect the affected runs’ workflow and job-level concurrency settings. Expand their expressions for the relevant event and compare the resulting group strings, including capitalization-insensitive matches. A workflow-level group and a job-level group can each affect concurrency; look at the configuration for the work that was canceled rather than assuming every run uses the same key.
Choose a group key that matches what should coordinate
Include dimensions that should separate work, such as workflow identity and branch or ref. Leave a dimension out only when you deliberately want those runs to coordinate—for example, when separate workflows deploy to the same environment.
Cancel obsolete checks for the same workflow and ref
For CI where only the newest commit on a branch needs to complete, GitHub documents this pattern:
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: trueThe workflow and ref make separate workflows and refs distinct, while the cancellation setting lets newer matching work supersede work already running. If only some branches should cancel running work, make cancel-in-progress an expression that reflects that policy rather than enabling it unconditionally.
Recommended Free Tools
Use a fallback when a context value may be absent
github.head_ref is available for pull-request events but may not be set for other event types. GitHub shows a fallback to the unique run ID for that situation:
concurrency:
group: ${{ github.head_ref || github.run_id }}
cancel-in-progress: trueChoose the fallback based on the intended coordination: a unique run ID prevents unrelated events without a head ref from joining one shared group.
Decide whether matching work should cancel, wait, or replace
| Work or goal | Group design | Policy to consider |
|---|---|---|
| CI checks made obsolete by a newer push | Workflow identity plus branch or ref | Set cancel-in-progress: true if stopping older work is acceptable. |
| Deployments to one shared environment | A deliberately shared environment or deployment key | Leave active work uncanceled; use a queue if each deployment must run. |
| Independent workflows or branches | Include workflow identity and the relevant ref | Keep group keys distinct to avoid unintended interaction. |
| Release or migration work that must finish | A dedicated release or target key | Do not cancel in-progress work; consider a queue for pending runs. |
To preserve the active run, omit cancel-in-progress or set it to false. That alone does not preserve every pending run: default single-pending behavior still replaces the older pending run when new work queues in the group.
To let more pending work wait, use queue: max:
concurrency:
group: production-deploy
queue: maxGitHub documents capacity for up to 100 pending jobs or workflow runs in this queue mode. Additional runs are canceled when the queue is full. queue: max cannot be combined with cancel-in-progress: true, so it is not a way to retain a backlog while also canceling active matching work.
Account for ordering and cancellation behavior
Concurrency is not a strict first-in, first-out guarantee based on workflow dispatch time. GitHub says work is processed according to when it started waiting on the group, and actual start time can vary. Do not rely on the group to guarantee that commits or deployments run in dispatch order.
Cancellation is not necessarily instantaneous. GitHub reevaluates running jobs’ if conditions during cancellation; a condition such as always() can keep a job running. For work selected for cancellation, the runner interrupts the step process and may escalate if it does not stop. GitHub documents a five-minute cancellation timeout before forced termination. See the workflow cancellation reference.
Check active groups when the YAML does not make the cause obvious
Inspect the affected run’s workflow and job configuration, then compare its resolved group with other active work in the repository. GitHub also documents a REST API endpoint for listing active concurrency groups: List pending deployments for a repository. Use the active group information alongside the workflow expressions; seeing matching names points to shared coordination, while the cancellation and queue settings determine what that match permits.
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.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →
