How to limit concurrent workflow runs

Use a custom queue somewhere. Have workflows check the queue before executing. If there’s a running workflow, add to the queue and exit early. Workflows can either trigger the next run before exiting or something else can coordinate workflow runs.

Not saying it’s perfect but good enough until the feature is implemented.

1 Like

Adding one more vote for the addition of this feature - would really be helpful for the work we do!  

This is exactly as my use case. Would love that feature.

1 Like

While waiting for a first-party solution, you can actually achieve this using a shell script and Google Cloud Storage. By locking an object in a storage bucket, you can ensure that only one instance of a job runs at a time.

Here is a script that implements the underlying locking

You’ll need to ensure that gsutil is available, and add lock and unlock steps to your workflow.

1 Like

How do you unlock it if the GitHub Workflow fails?


I asked something similar not long ago is what I came up with


Any update on this? Is there a deadline, is it still planned, is it on hold?


We just use softprop’s turnstyle action. As the comment inside says - we wait for up to a minute for previous run to complete and abort the new run if previous one is not done by then.


  # Wait for up to a minute for previous run to complete, abort if not done by then
    runs-on: ubuntu-latest
    timeout-minutes: 1
      - name: 'Block Concurrent Executions'
        uses: softprops/turnstyle@v1
          poll-interval-seconds: 10
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

    needs: pre-ci
    runs-on: ubuntu-latest

This is a very common use case, and one that we’ve been trying to sort out as well. As others have stated, in a fast moving CD company, we often merge one PR after the next and the last thign we want is for that to result in n deployments.

I’m attempting to work around this by using semantic-release to create releases, then have a separate workflow that triggers on release and performs deploy. When multiple changes get merged into master at roughly the same time, only the latest one will successfully create a release since the others will fail due to there being new commits since the workflow run began.

It’s not perfect, but I anticipate it will work… If only I could get past this 500 error issue I’m getting on release workflows

Good Day to all, any update about this? thanks


See post referencing Turnstyle.

I added the action and it blocked until the already running action completed.

Thanks @softprops . I’d consider this featured request solved.

Thanks Github for making Actions flexible enough to allow the community to help make Actions feature rich.


If actions happen fast, there are a lot of room for two actions getting green light and starting at the same time.
Quite easy to reproduce with repository dispatch event and curl. Just do two at the same time, and you’ll get two running actions at the same time. Race condition, because there is no real lock acquired by the action, only checking if no actions run at current point in time.

1 Like

Thank you @softprops for Turnstyle.

Unfortunately with one of my repositories I have many jobs (>40) and despite setting the poll-interval-seconds high I do hit GitHub API limits. I think that there is still value in a GitHub-official solution to this problem.


edit: I misinterpreted the in progress view of my deployment actions. Turnstyle does in fact allow my staging and production deploys to run in parallel.

I think Turnstyle is a clever solution but only for certain deployment setups. It’s not general purpose. Our deployment workflow has parallel jobs for staging and production, but those are considered separate runs and Turnstyle serializes them.

We need either a workflow-level concurrency limit, a mutex primitive, or best of all a queue primitive (to avoid wasted minutes).

Would also like this feature. With the Turnstyle solution, it can eat a lot of minutes waiting for a deployment which can take ~10mins to deploy especially if we have a backlog of >10 commits staged for deployment.

1 Like

Any update on this request?


This is a crucial feature, we need to be able to limit the number of parallel runs for certain workflows.

1 Like

In the meantime I found Hope this helps. But we definitely need such a feature …

Can try this script