RFE Add option to automatically cancel workflow/job when pull request is closed

[pbrezina]

Why are you starting this discussion?

Product Feedback

What GitHub Actions topic or product is this about?

Workflow Configuration

Discussion Details

We have multiple long-running PR CI checks that runs on pull_request or pull_request_target events. If the pull request is closed, I would like running jobs to be cancelled to avoid wasting resources and runners.

[Danindu05]

This is a great suggestion — it would definitely help optimize CI resource usage.

In the meantime, you can achieve a similar effect manually by adding a conditional step to your workflow that cancels running jobs when a PR is closed. For example:

on:
pull_request:
types: [opened, synchronize, reopened, closed]

jobs:
build:
if: github.event.action != 'closed'
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Build
run: echo "Running build..."

cancel:
if: github.event.action == 'closed'
runs-on: ubuntu-latest
steps:
- name: Cancel running workflows
uses: styfle/cancel-workflow-action@0.12.1
with:
access_token: ${{ github.token }}

This uses styfle/cancel-workflow-action
to automatically cancel previous or concurrent runs when the PR is closed — effectively preventing wasted resources.

That said, having a native GitHub Actions setting (like cancel-on-close: true) would make this much cleaner and more reliable. Your RFE makes total sense — it would be great to see this built-in.

[pbrezina]

The problem with this workaround is that it requires the runner to be available. If we are already out of resources, the cancel job will be queued and thus not clearing up the resources.

[IsmaFerror]

Hi 👋
Great question — this is a common concern for long-running CI checks!
You can automatically cancel in-progress workflows when a pull request is closed by combining two approaches:

✅ Option 1: Use the built-in concurrency feature

This is the simplest and most reliable method.
Add this to the top of your workflow:

name: PR CI

on:
pull_request:
types: [opened, synchronize, reopened, closed]

concurrency:
group: ${{ github.workflow }}-${{ github.event.pull_request.number }}
cancel-in-progress: true

jobs:
build:
if: ${{ github.event.action != 'closed' }}
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: echo "Running CI for PR #${{ github.event.pull_request.number }}"

🧠 How it works:

concurrency ensures only one run per PR is active.

When the PR is closed, the if condition skips jobs.

Any still-running runs for that PR get cancelled automatically.

✅ Option 2: Explicitly cancel via the REST API (if you prefer control)

If you want to cancel all running workflows when a PR is closed:

on:
pull_request:
types: [closed]

jobs:
cancel-ci:
runs-on: ubuntu-latest
steps:
- name: Cancel running workflows for this PR
uses: octokit/request-action@v2.x
with:
route: DELETE /repos/${{ github.repository }}/actions/runs/${{ github.run_id }}
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

But in most cases, Option 1 (concurrency) is all you need — lightweight, built-in, and effective.

Hope this helps keep your runners free and your workflow efficient 🚀
(If this solves your question, please mark it as the accepted answer so others can find it easily!)

[Danindu05]

You’re absolutely right — the cancel-workflow-action approach still needs a runner, which doesn’t help when the queue is already full.

The most reliable workaround right now is to use the built-in concurrency feature in your workflow. It lets you group runs under the same key and automatically cancel any in-progress ones when a new run starts or when the PR is closed.

Example:

on:
pull_request:
types: [opened, synchronize, reopened, closed]

concurrency:
group: ${{ github.workflow }}-${{ github.event.pull_request.number }}
cancel-in-progress: true

jobs:
build:
if: github.event.action != 'closed'
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: echo "Running build..."

This setup ensures:

Any new commit cancels the previous run for the same PR.

When the PR is closed, the if condition prevents new jobs from starting.

It’s not a full controller-level cancel (since GitHub doesn’t yet support native cancel-on-close), but it’s the best currently available method to avoid wasting runners.

[sssd-bot]

Thank you for your replies. However, neither is the solution. The cancellation via API requires a runner to be available, which is not always the case. The concurrency requires the same job to be executed twice - it does not cancel the last job until a new job is available. This does not free the runners for other, non-related jobs.

This really can not be achieved without a support in the workflow implementation itself. This is a request to implement something like cancel-on-close: true option in the workflow and job specification.

[barb4rian]

Why are you starting this discussion?

Product Feedback

What GitHub Actions topic or product is this about?

Workflow Configuration

Discussion Details

We have multiple long-running PR CI checks that runs on pull_request or pull_request_target events. If the pull request is closed, I would like running jobs to be cancelled to avoid wasting resources and runners.

You can achieve this by triggering a lightweight workflow when a PR is closed and canceling any in-progress workflows for that same PR.

name: Cancel CI on Closed PR

on:
pull_request:
types: [closed]

jobs:
cancel:
runs-on: ubuntu-latest
steps:
- name: Cancel running workflows for this PR
uses: styfle/cancel-workflow-action@0.12.1
with:
access_token: ${{ github.token }}

This ensures that when a pull request is closed, all long-running jobs are immediately canceled, preventing wasted runner time.

You can also use the built-in concurrency
feature in your main CI workflows:

concurrency:
group: ci-${{ github.ref }}
cancel-in-progress: true

Together, these options automatically clean up CI runs when PRs are closed — a simple but effective way to save resources.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬