Restoring Parallel Step Execution in Bitbucket Pipeline after self hosted runner upgrade

Platform Notice: Cloud Only - This article only applies to Atlassian apps on the cloud platform.

Summary

This article helps you restore parallel step execution in Bitbucket Pipelines when self‑hosted runners stop running steps concurrently after upgrading the runners to version 5.x.

Diagnosis

Check your plan's concurrency limits:

  • Review your Bitbucket plan to determine your allowed number of concurrent build slots:

    • Standard plan: 1 concurrent build slot

    • Premium plan: 2 concurrent build slots

  • If you need to run more steps in parallel, consider upgrading your plan or purchasing additional build slots. For more details, see the Bitbucket blog on runner pricing and features.

Cause

Starting with version 5.x, Bitbucket Pipelines self-hosted runners enforce new concurrency limits based on your Bitbucket plan. For example, Standard plans allow only one concurrent build slot, and Premium plans allow two. This means that even if you register multiple runners, only the allowed number of steps will run in parallel; additional steps will be queued. This change can prevent parallel steps from running as expected after upgrading runners. In some cases, communication problems between runners and the Bitbucket backend, or incorrect YAML configuration, can also cause parallel steps to remain queued or run sequentially (one after another).

Solution

Resolve runner communication issues:

  • If steps remain queued or do not start, there may be a communication issue between your self-hosted runner and Bitbucket Pipelines.

  • Delete and recreate the affected runner:

    • Go to your repository preferences.

    • Navigate to Runners.

    • Select the problematic runner, click the three dots, and choose Delete.

    • Add a new runner following the standard setup process.

Downgrade to a previous runner version (if needed):

  • If you want to revert your Docker self-hosted runner to a previous version (such as a 3.x image) to restore previous behavior:

    • Stop and remove the current runner container.

    • Remove the version 5 image using below command.

      docker image rm docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner:5

    • When spinning up a new runner, append the 4 tag to the image to ensure the runner will pull and use version 3.

      docker-public.packages.atlassian.com/sox/atlassian/bitbucket-pipelines-runner:3

    • Start a new container using that specific image tag and your existing configuration/volume mounts.

  • You can use the latest available 3.x Docker image tag if preferred, as long as it is still supported.

Additional notes

  • If you are using parallel steps within a stage, this is not supported. Watch the open feature request for updates.

  • If you encounter issues with stuck or queued steps, and deleting/recreating the runner does not help, contact Atlassian Support for manual intervention.

Updated on February 17, 2026

Still need help?

The Atlassian Community is here for you.