Bitbucket Cloud · Pipelines · Checked November 2, 2026

Bitbucket Pipelines: parallel steps that don't behave as expected

A parallel group runs its steps at the same time. Results come sooner, but the build minutes stay the same: each step counts on its own ("You've run out of build minutes"). Most surprises come from what one step in the group can and can't do to the others.

- parallel:
    steps:
      - step:
          name: Unit tests
          script:
            - ./unit-tests.sh
      - step:
          name: Integration tests
          script:
            - ./integration-tests.sh

The other steps keep running after one fails

In Atlassian's Parallel step options, fail-fast is false by default. When the unit tests fail after a minute, the integration tests still run to their end and use their build minutes. To stop the whole group as soon as one step fails:

- parallel:
    fail-fast: true
    steps:
      - step:
          name: Unit tests
          script:
            - ./unit-tests.sh
      - step:
          name: Upload metadata
          fail-fast: false
          script:
            - ./upload-metadata.sh

fail-fast can also go on one step. fail-fast: true on a step stops the group when that step fails; fail-fast: false on a step, as on the upload above, lets it fail without stopping the others.

A step that may fail, or should try again

on-fail in Step options works on a step, a parallel group or a stage:

• strategy: ignore: the step shows as failed, but the pipeline does not fail because of it. Useful for a lint step that should not block the tests next to it.
• strategy: retry with maxRetryCount from 1 to 10 (1 by default): the step runs again. Set on the group, it applies to every step, and a step can set its own.

Two rules from the same page. Only the default strategy: fail works together with fail-fast: with fail-fast on the step or on any step of the same group, ignore and retry are turned off. And on-fail can't be used on deployment steps.

Files and variables between the steps

• A parallel step can use artifacts from the steps before the group, not from the other steps in its group (The artifact is missing in the next step).
• The steps after the group get the files of all its steps together. When two parallel steps write a file at the same path, the file from the step written later in the YAML wins, file by file.
• Variables written in a parallel step are not passed to any later step (A variable is empty). Put a step that computes values before the group.
• Parallel steps can read caches but not save them (The cache is not used). Atlassian suggests caching the dependencies in a first step, then running the tests in parallel.

Splitting tests across the steps

Each step of a group has BITBUCKET_PARALLEL_STEP, its place in the group starting at 0, and BITBUCKET_PARALLEL_STEP_COUNT, the number of steps. One way to give each step its share of the test files:

script:
  - files=$(find tests -name '*_test.py' | sort | awk -v n="$BITBUCKET_PARALLEL_STEP_COUNT" -v i="$BITBUCKET_PARALLEL_STEP" 'NR % n == i')
  - '[ -n "$files" ] || exit 0'
  - pytest $files

We ran the line with GNU Awk 5.3 for 2 and 3 steps over 7 test files: each file went to exactly one step. The sort keeps the order the same in every step. The empty check matters when there are more steps than files: pytest with no file names runs the whole suite.

Limits

• A pipeline can have up to 100 steps, and each step in a parallel group counts.
• All deployment environments in one parallel group must be of the same type: no production and test in the same group.
• There is a limit on steps running at once across the workspace. Parallel step options gives 600 for Standard and Premium workspaces and 10 for Free, and says steps over the limit fail. Atlassian's article "Seems like you're running a lot of pipelines at the same time" error message (updated September 26, 2025) gives 100, counting parallel steps.

That article's message is the one a build gets at the limit:

Seems like you're running a lot of pipelines at the same time. This is usually due to an accidental push. To conserve your minutes, we won't run them all.

It is the same message as for a push with more than five branches or tags (A push that started no pipeline). Atlassian has a bug for the shared message, BCLOUD-22077, open since August 2022. The fix from the article: look for repositories running more builds than expected, and remove parallelism from builds that don't need it.

Self-hosted runners that run parallel steps one by one

Atlassian's article Restoring Parallel Step Execution in Bitbucket Pipeline after self hosted runner upgrade (updated February 17, 2026): from runner version 5.x, the plan sets how many steps run at once on your runners, one for Standard and two for Premium, however many runners you register. The other steps wait in the queue. The article points to buying more build slots or a higher plan, and describes going back to a 3.x runner image. It also notes that parallel steps inside a stage are not supported on runners.

Bitbucket 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, with their steps, the failed step and the command it stopped at, and the step's log as Bitbucket writes it. 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 Atlassian or JetBrains.

More: A step skipped by condition: changesets (includePaths) · Git LFS files that arrive as pointers, and LFS pushes from a step · Git commands that fail in a shallow clone (origin/main, git describe) · The scheduled pipeline did not run · "Container 'build' failed to pull image" · "Connection refused" to a service (MySQL, PostgreSQL, Redis) · "Not authorized to perform sts:AssumeRoleWithWebIdentity" (OIDC to AWS) · Test results not showing · A variable is empty · "Host key verification failed" (SSH) · "Cannot connect to the Docker daemon" · "authorization denied by plugin pipelines" (Docker) · "Container 'docker' exceeded memory limit." · Pipelines did not run after a push · "Container 'Build' exceeded memory limit." · "Exceeded build time limit of 120 minutes" · The cache is not used · "unexpected system error" · "command not found" · Submodules not cloned · "We couldn't clone the repository" · "No online runner available" · "No space left on device" · "Step exceeded processing limits" · The artifact is missing in the next step · The build passed before and fails now · Build setup takes too long · "You've run out of build minutes" · "Permission denied to update branch" · "You have reached your pull rate limit" (Docker Hub) · "There is an error in your bitbucket-pipelines.yml" · "This pipeline was paused" (deployments) · Bitbucket Pipelines plugins for IntelliJ IDEA, compared · 日本語