Bitbucket Pipelines: stopPipeline returns 204, but runs remain paused/halted

[simpleconstellation]

In our workspace, 16 historical pipelines remain IN_PROGRESS with PAUSED or HALTED substates:

We called POST /2.0/repositories/{workspace}/{repo_slug}/pipelines/{pipeline_uuid}/stopPipeline for each run. All requests returned HTTP 204, but repeated API checks show unchanged states.

No steps are executing, and our self-hosted runners are idle. The runs are superseded; we want to cancel them while preserving their history, without resuming old deployment steps.

Could anyone confirm how to finalize these runs and whether this is a known limitation or bug? 


Thank you very much!

[Jovânio Junior]

Hi simpleconstellation – Welcome to the Atlassian Community!

A 204 from stopPipeline only means Bitbucket accepted the stop signal; it does not guarantee that the pipeline has already transitioned to COMPLETED/STOPPED. Atlassian’s API documentation states that the endpoint “signals” the pipeline and its unfinished steps to stop.

PAUSED/HALTED pipelines are a special case because they can still be represented as IN_PROGRESS even when no runner is actively executing anything. This commonly happens with deployment concurrency, deployment permissions, or manual steps.

If these 16 pipelines are historical, superseded, have no active steps, and remain unchanged after repeated stop requests, I would treat that as a likely stuck state rather than keep resuming them just to cancel them.

I’m not aware of a separate public API to forcibly mark an existing pipeline as COMPLETED/STOPPED. At that point, I’d raise a Bitbucket Cloud support ticket and include a few affected pipeline UUIDs, the 204 responses, and the current state/stage payloads so Atlassian can confirm whether they need backend cleanup or whether this is a known defect.