Your GitHub Actions workflow was cancelled because a newer, concurrent run of the same workflow started. This is a deliberate feature, not a bug, designed to prevent wasted resources by automatically cancelling older, potentially obsolete runs when a fresh one kicks off.
Here’s how to diagnose and fix this:
Cause 1: Frequent Commits or Pushes to the Same Branch
Diagnosis: Check your GitHub repository’s "Actions" tab and filter by the specific workflow. You’ll likely see many runs with a "cancelled" status, often happening in quick succession. Look at the timestamps of these runs.
Fix:
If this is happening due to rapid, iterative commits, you can adjust the concurrency setting in your workflow file. Instead of cancelling on a new run, you can group runs by a specific identifier and only allow one to proceed.
name: My CI Workflow
on:
push:
branches:
- main
pull_request:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: false # Set to false to prevent cancellation
Why it works:
By setting cancel-in-progress: false, you tell GitHub Actions not to cancel any currently running jobs when a new one starts for the same group. The new run will simply queue up and wait for the previous one to finish, preventing the "cancelled by newer run" error. The group ensures that only runs for the same workflow and branch are considered for concurrency.
Cause 2: Multiple Pushes to a Branch Almost Simultaneously
Diagnosis:
Similar to Cause 1, but the runs might be more spread out, yet still overlapping in a way that triggers the cancellation. This can happen if you or a team member push multiple commits to the same branch within a short timeframe, or if CI triggers on both push and pull_request events for the same branch and they happen concurrently.
Fix:
The same concurrency setting as in Cause 1 applies here. Explicitly setting cancel-in-progress: false is the key.
name: My CI Workflow
on:
push:
branches:
- develop
pull_request:
branches:
- develop
jobs:
lint:
runs-on: ubuntu-latest
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: false
Why it works:
This configuration ensures that even if two pushes occur very close together on the develop branch, the second workflow run will wait for the first one to complete instead of being cancelled. This guarantees that every push gets a chance to be fully processed.
Cause 3: Workflow Triggered by Multiple Event Types
Diagnosis:
Your workflow might be configured to run on both push and pull_request events for the same branches. If a push happens while a pull request for that same branch is open and being built, the push event can trigger a new run that cancels the pull_request run, or vice versa.
Fix: You can use a more specific concurrency group or explicitly disable cancellation for one of the event types if they are causing interference. A common pattern is to use different concurrency groups for different event types if you don’t want them to interfere.
name: My CI Workflow
on:
push:
branches:
- main
pull_request:
branches:
- main
jobs:
test:
runs-on: ubuntu-latest
concurrency:
group: ${{ github.workflow }}-${{ github.event_name }}-${{ github.ref }} # Differentiate by event
cancel-in-progress: false
Why it works:
By including ${{ github.event_name }} in the concurrency group, you create separate groups for push and pull_request events targeting the same branch. This means a push run won’t cancel a pull_request run and vice versa, as they are now managed independently by the concurrency settings.
Cause 4: Using a Shared Branch for Multiple Independent Changes
Diagnosis:
If multiple developers are pushing features or fixes to a single shared branch (e.g., develop) without merging them into feature branches first, each push can trigger a new workflow run, leading to cancellations.
Fix:
Encourage developers to use feature branches for their work and merge into develop via pull requests. For the develop branch workflow, you can use the cancel-in-progress: false setting.
name: My CI Workflow
on:
push:
branches:
- develop
jobs:
deploy:
runs-on: ubuntu-latest
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: false
Why it works:
This reinforces the idea that the develop branch workflow should process each push sequentially. By preventing cancellation, you ensure that every commit on develop gets a chance to pass its checks, even if multiple commits are made in rapid succession before a PR is created.
Cause 5: Re-running a Workflow Manually
Diagnosis: When you manually re-run a workflow from the Actions UI, it starts a new run. If the original run was still in progress, the new manual run will cancel the old one.
Fix:
If you intend to re-run a workflow to debug a specific issue or apply a change, and the previous run is still active, consider waiting for the previous run to complete or explicitly cancelling the previous run yourself before initiating the re-run. Alternatively, use the cancel-in-progress: false setting as described above.
name: My CI Workflow
on:
push:
branches:
- main
jobs:
build-and-test:
runs-on: ubuntu-latest
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true # Default, but explicit for clarity
Why it works:
While cancel-in-progress: true is the default and causes the cancellation, understanding this behavior helps you manage manual re-runs. If you don’t want cancellation, you’d switch this to false. For manual re-runs specifically, it’s often about awareness: if you see a run in progress and click "Re-run failed jobs," you are intentionally triggering a cancellation.
Cause 6: Using workflow_run Trigger with Concurrent Pushes
Diagnosis:
If you have a workflow_run trigger that depends on another workflow, and the source workflow is triggered by frequent pushes, the dependent workflow might be cancelled if a new run of the source workflow starts before the dependent one finishes.
Fix:
The concurrency setting can be applied to the workflow that has the workflow_run trigger.
name: My Dependent Workflow
on:
workflow_run:
workflows: ["My Source Workflow"]
types:
- completed
jobs:
deploy:
runs-on: ubuntu-latest
concurrency:
group: ${{ github.workflow }}-${{ github.event.workflow_run.id }} # Unique per source run
cancel-in-progress: false
Why it works:
By setting cancel-in-progress: false on the dependent workflow, you ensure that once a job is triggered by a workflow_run event, it will complete its execution regardless of whether another run of the source workflow starts. The concurrency group here is often tied to the specific workflow_run.id to ensure each instance is distinct.
The next error you’ll likely encounter is related to resource limits or job timeouts, as your workflows will now be running to completion more consistently.