Bitbucket "Your build exceeded the maximum build time"

By Daniel Zoghalchali·Latchkey

A step ran longer than its build-time limit (120 minutes by default, configurable via max-time) and Bitbucket killed it. The step is stopped mid-run, not failed by your code.

What this error means

A step is terminated with "Your build exceeded the maximum build time and was stopped." The logs simply cut off where the limit hit - there is no error from your own command.

Bitbucket log

Your build exceeded the maximum build time and was stopped.

Diagnose it: schema, branch match, or step isolation?

Bitbucket validates the pipeline file on push, and a schema error disables the pipeline rather than failing a build, which looks like nothing happened. Each step also runs in a fresh container, so nothing carries between steps unless declared.

Terminal

curl -X POST -H "Content-Type: application/x-yaml" \
  --data-binary @bitbucket-pipelines.yml \
  https://api.bitbucket.org/2.0/repositories/<workspace>/<repo>/pipelines/validate

Common causes

The step genuinely takes too long

A slow test suite, large build, or heavy install can exceed the default 120-minute cap (or a lower max-time you set).

A hang or deadlock

A command waiting on input, a deadlocked test, or a process that never exits will run until the limit and then be killed.

How to fix it

Raise the step max-time

Set max-time (in minutes) on the step or globally. The cap depends on your plan; you cannot exceed the plan maximum.

bitbucket-pipelines.yml

pipelines:
  default:
    - step:
        name: Slow tests
        max-time: 120
        script:
          - ./run-tests.sh

Split and parallelize the work

Break one long step into parallel steps so each finishes well under the limit.

bitbucket-pipelines.yml

- parallel:
    - step: { script: [ ./test.sh unit ] }
    - step: { script: [ ./test.sh integration ] }

Find and fix the hang

Add timeouts to network calls and test runners so a hang fails fast.
Ensure no command waits on stdin in CI.
Cache dependencies so install time does not eat the budget.

How to prevent it

Cache dependencies and build outputs to cut step duration.
Parallelize long test suites across steps.
Add per-command timeouts so hangs surface quickly.

Frequently asked questions

What causes Bitbucket "Your build exceeded the maximum build time"?

There are 2 common causes: the step genuinely takes too long and a hang or deadlock. A slow test suite, large build, or heavy install can exceed the default 120-minute cap (or a lower max-time you set).

How do I fix Bitbucket "Your build exceeded the maximum build time"?

There are 3 fixes depending on which cause you have: raise the step max-time, split and parallelize the work, and find and fix the hang. Work through them in order, since the first is the most common.

What does Bitbucket "Your build exceeded the maximum build time" actually mean?

A step is terminated with "Your build exceeded the maximum build time and was stopped." The logs simply cut off where the limit hit - there is no error from your own command.

How do I stop Bitbucket "Your build exceeded the maximum build time" happening again?

Cache dependencies and build outputs to cut step duration. The prevention section lists 3 changes that keep it from recurring.

Can Latchkey fix this automatically?

Yes. Latchkey runs your GitHub Actions on managed runners that detect this failure, apply the fix, and retry the job automatically - self-healing is on by default.

References

GitHub Actions documentation