Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →cancel-in-progress: true tells GitHub Actions to cancel matching work that is already running when new work enters the same concurrency group. The group determines what matches; the setting does not guarantee that a deployment or other external side effect will be rolled back.
What does cancel-in-progress do?
GitHub Actions concurrency lets you control which workflow runs or jobs may run at the same time. With cancel-in-progress: true, new work entering a concurrency group cancels the currently running job or workflow run in that same group. GitHub documents the setting in its workflow syntax reference.
As an Amazon Associate I earn from qualifying purchases.
The option does not identify the work to cancel on its own. The group value does that: matching group names share the concurrency policy. Groups are case-insensitive, so changing only capitalization does not create a separate group.
Recommended Free Tools
Choose the scope and group deliberately
Workflow-level concurrency
Place concurrency at the workflow level when the entire run is the unit to manage. A common branch-specific configuration is:
#1 Best Overall
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: trueThis combines the workflow name and ref so newer work for the same workflow and ref can cancel the older run. The workflow component also reduces accidental collisions with a different workflow using the same ref. If separate workflows reuse an identical group, they can cancel one another’s matching work.
Job-level concurrency
Put the setting on an individual job when only that job should be serialized or canceled, while other jobs in the workflow may continue:
jobs:
test:
runs-on: ubuntu-latest
concurrency:
group: test-${{ github.ref }}
cancel-in-progress: trueUse a group name that reflects the work you intend to coordinate. A broad or static group can make unrelated runs compete; an expression can narrow the group to a workflow, branch, or other context.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Expressions and event-specific values
A context property may be undefined for some events. GitHub shows a fallback such as ${{ github.head_ref || github.run_id }} to provide a group value for events without a head ref and keep those runs distinct.
cancel-in-progress can itself be an expression. For example, GitHub documents conditional cancellation that applies to non-release branches but not release branches. That can allow development work to supersede older runs while preserving release runs.
How pending work differs from active cancellation
Concurrency has separate behavior for queued work and running work. The default queue: single policy allows one active item and at most one pending item per group. If another item is queued while one is already pending, the newer item replaces—and cancels—the existing pending item. This can happen even when cancel-in-progress is not enabled.
| Configuration | Pending work | Currently running work |
|---|---|---|
Default queue: single, without active cancellation |
At most one pending item; a newly queued item replaces the pending one. | Continues running. |
queue: single with cancel-in-progress: true |
At most one pending item; a new item replaces the pending one. | Matching active work is canceled when new work enters the group. |
queue: max |
Up to 100 pending jobs or workflow runs; additional items are canceled when the limit is reached. | Cannot be combined with cancel-in-progress: true. |
GitHub describes ordering as FIFO based on when work began waiting in the concurrency group, but warns that actual start times can vary and ordering is not guaranteed. Do not rely on concurrency as a strict dispatch-order queue. See the concurrency syntax documentation for the current settings and limits.
Does it cancel the whole workflow?
It depends on where concurrency is configured. Workflow-level concurrency manages the workflow run; job-level concurrency applies to that job. With job-level control, other jobs may proceed rather than having the entire run treated as the concurrency unit.
Does canceling a workflow undo a deployment?
No rollback should be assumed. GitHub documents cancellation of matching in-progress Actions work, but does not promise that cancellation reverses an external operation that a script or deployment has already completed or started. That is a boundary of the documented feature, not a rollback guarantee.
If a deployment must recover from interruption, design that behavior in the deployment process—for example, with explicit cleanup, rollback steps, or idempotent operations where appropriate. Those safeguards are application-level design choices, not effects guaranteed by cancel-in-progress.
Concurrency groups are not environments
A concurrency group and a GitHub Actions environment are distinct controls. GitHub states in its deployment guidance that “concurrency” and “environment” are not connected. Using an environment name does not automatically place a workflow in a matching concurrency group; configure concurrency explicitly if you need that behavior.
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.
