Bitbucket Step "max-time" Too Low - Step Stopped Early

You set a per-step max-time lower than the step actually needs, so Bitbucket stops the step when the timer expires - not because the work failed, but because the cap was too tight.

What this error means

A step is stopped at exactly the max-time you set, with the log cutting off mid-command. Removing or raising max-time lets it finish, confirming the cap - not the code - was the limit.

Bitbucket log

Step exceeded its configured max-time of 10 minutes and was stopped.

Common causes

max-time set below the real runtime

A max-time: 10 on a step that legitimately takes 14 minutes will always be killed at 10. The cap is a safety limit, not a target.

Occasional slow runs exceed a tight cap

A step that usually finishes in 8 minutes but sometimes takes 12 (cold cache, slow network) intermittently trips a 10-minute cap.

How to fix it

Raise max-time to cover the work

Set max-time comfortably above the step’s typical worst case, within your plan’s maximum.

bitbucket-pipelines.yml

- step:
    name: Integration tests
    max-time: 30
    script: [ ./integration.sh ]

Speed the step up if the cap is intentional

Cache dependencies so cold runs are not far slower.
Parallelize the slow part so each step finishes well under the cap.
Only keep a tight max-time if you truly want to fail slow runs fast.

How to prevent it

Set max-time above the step’s realistic worst case.
Cache to keep run times consistent under the cap.
Reserve tight caps for steps where a slow run is itself a failure signal.