Understanding Job Cancellation in GitHub Actions: Can You Make a Specific Job Uncancellable?

Managing workflows efficiently is essential when automating your projects with GitHub Actions. A common scenario involves controlling how concurrent workflow runs are handled—especially when certain jobs should persist despite new workflows initiating. This raises an important question: Is it possible to designate a specific job within a GitHub Actions workflow as non-cancellable?

In typical setup, you might define concurrency settings at the workflow level like this:

yaml
concurrency:
cancel-in-progress: true
group: main-${{ github.ref_name }}

This configuration ensures that if a new workflow run is triggered for the same branch or reference, any in-progress workflows within the same group are cancelled to avoid redundancy.

However, when assigning concurrency settings directly to individual jobs, you might expect to have more granular control. For example:

yaml
deploy:
concurrency:
cancel-in-progress: false
group: main-deploy-${{ matrix.app }}

The intention here is clear: the deploy job should not be cancelled even if a new workflow is triggered within the same group—making it “uncancellable.” Nevertheless, in practice, the deploy job still ends up being cancelled when a new workflow starts within its group.

This behavior stems from how GitHub Actions manages concurrency: the per-job concurrency setting does not override the grouping at the workflow level. Instead, the group defined at the workflow scope governs whether jobs are cancelled or run concurrently. Setting cancel-in-progress: false at the job level does not guarantee its permanence against workflow-level cancellation policies.

What Can You Do?

Currently, there isn’t a built-in method to mark a single job as entirely uncancellable once the workflow has been triggered. To achieve persistent deployment jobs that survive workflow cancellations, consider these approaches:

• Use Separate Workflows: Run critical deployment jobs in dedicated workflows with their own concurrency policies, ensuring they are independent of other workflows.

• Implement Retry Logic: Configure your deployment job to detect if it was cancelled and automatically retry or resume.

• External Locking Mechanisms: Employ external systems or flags (like a database or file system) to prevent multiple overlapping deployments, effectively controlling job concurrency at an external level.

Conclusion

While GitHub Actions provides robust concurrency controls, marking individual jobs within a workflow as absolutely uncancellable requires creative workarounds. As of now, the key is to