Bitbucket Pipelines: "This pipeline was paused"
A pipeline that stops at a deployment step without failing shows Paused. Nothing broke: Bitbucket is holding the deployment, and the pipeline page says why. Two of the messages, from Atlassian's support:
This pipeline was paused because Test can not be deployed to from the glob branch. This pipeline was paused because Production can only be deployed to from permitted branch pipelines.
There are three reasons: another deployment to the same environment is running, the branch may not deploy there, or the person may not.
Another deployment to the same environment is running
Only one deployment per environment runs at a time. Before a step with deployment: starts, Pipelines checks for a deployment in progress to that environment, and later pipelines deploying there are halted (Concurrency control). Once the running one completes, you can resume the paused pipeline at the step where it halted, or rerun the whole pipeline. For years it did not resume by itself: Atlassian's support said so in August 2022 (thread), and the request BCLOUD-16304 had 480 votes.
In June 2025 Atlassian closed that request with concurrency groups (Atlassian's announcement). Steps with the same concurrency-group run one at a time, first in, first out, and a queued step resumes by itself when the one before it finishes. Put it next to deployment:, and the group's queue takes the place of the deployment lock while the step stays on the Deployments dashboard:
- step:
name: Deploy to production
deployment: production
concurrency-group: production
script:
- ./deploy.sh
A queued step shows Waiting to run until its turn comes. The group is just a name, with nothing to set up first, and it works across the repository's pipelines; the option is in Step options. If you do not need one-at-a-time deployments at all, the environment: keyword from the same release gives a step the environment's variables and its admin and branch checks without the deployment lock, so several steps can use one environment at once; such a step is not tracked on the Deployments dashboard.
The branch may not deploy to the environment
On Premium, an environment's settings (Repository settings > Pipelines > Deployments) can list the Branches allowed to deploy to it. A push to another branch still starts the pipeline, and the pipeline pauses with the first message above (Atlassian's article). If the branch should deploy, add it to the list. When the button that starts a deployment on the pipeline page is grayed out, hovering over it shows the reason, such as a branch not on the list (Atlassian's article).
Two cases pause even though the commit is on an allowed branch:
- A deployment under
tags:: the second message above. With a branch restriction, Pipelines allows the deployment only in the definition of an allowed branch, not in the one for tags, Atlassian's support answered in July 2021 (thread). The request to allow tags, BCLOUD-21048, is still Gathering Interest (63 votes). - Run pipeline from the Commits page: the pipeline checks out the commit, not a branch (a detached HEAD), so the branch check fails. Atlassian's way round it is a custom pipeline run on the branch, which then resets to the commit you give it (Atlassian's article): run it from Branches, the branch's … menu, Run pipeline for a branch, and enter the commit hash.
pipelines:
custom:
run-test-for-environment:
- variables:
- name: commithash
default: HEAD
- step:
script:
- git reset --hard ${commithash}
- echo "build is running"
The person may not deploy
On Premium, the same settings page can Allow only admins to deploy to this environment, or Allow selected users or groups to deploy to this environment (Set custom deployment permissions). Then only the admins, or the users and groups on the list, can trigger the deployment. Scheduled and automatically started pipelines are held too, and someone allowed has to resume them. An environment uses one or the other, admin-only or the list, and the list holds up to 100 users and groups. People on it still need write access to the repository to run pipelines.
If you read the status from the API
Atlassian's table (Differences between Bitbucket pipelines status from UI and API results): a paused pipeline is IN_PROGRESS with no result in the REST API. A pipeline whose automatic steps all passed and whose manual step waits is shown as Successful on the web page, but is also IN_PROGRESS in the API. The API's schema names two stages of IN_PROGRESS, RUNNING and PAUSED.
See paused pipelines in IntelliJ IDEA
Pipeline Inbox for Bitbucket Pipelines, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the pipelines of all your Bitbucket Cloud repositories in an IDE tool window. When a pipeline waits at a manual step, the details link to that step on Bitbucket. When it is paused and no step is manual, the details say that Bitbucket may be holding a deployment (another deployment to the same environment, or a branch or person not allowed there) and that the pipeline page on Bitbucket says why. Resuming is on Bitbucket's page; with Pro, Run again starts a new pipeline on the same commit, branch or pull request from the IDE. The list, steps and logs are free; running, re-running and stopping pipelines are Pro (US$1.50 a month, with a 30-day trial).
Get it on JetBrains Marketplace
Atlassian, Bitbucket and Bitbucket Pipelines are trademarks of Atlassian; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by any of them.
More: Rerunning a failed pipeline · Running a custom pipeline with variables · Pipelines did not run after a push · "Permission denied to update branch" · "There is an error in your bitbucket-pipelines.yml" · Bitbucket Pipelines plugins for IntelliJ IDEA, compared · 日本語