GitLab documents a REST endpoint, POST /projects/:id/pipelines/:pipeline_id/cancel, that marks a pipeline as canceled and asks the runner to terminate its active jobs. Job-level timeouts and runner-side SIGTERM handling are separate documented mechanisms that interact with cancellation. Assume a current release line (GitLab 17.x) on SaaS or self-managed instances.The unresolved part is scope. Downstream pipelines started through trigger (bridge) jobs appear as separate pipelines, and the documented cancel endpoint takes a single pipeline ID with no cascade option called out. Whether canceling the parent should stop same-project child pipelines, multi-project downstream pipelines, or neither is not clearly defined, so teams automating cancellation cannot tell which pipelines they remain responsible for. A related ambiguity is the final status reported when a job's timeout expires while cancellation is already in flight.Behavior may also differ between Community and Enterprise editions and across runner versions, so this needs confirmation against current documentation before automation is built on it.Does canceling a parent pipeline cascade to same-project child pipelines, and to multi-project downstream pipelines?If not, is canceling each downstream pipeline individually the intended contract for API consumers?When timeout and cancellation race, which final job status is authoritative?

Cancellation Scope for Downstream Pipelines Canceling a parent pipeline via the POST /projects/:id/pipelines/:pipeline_id/cancel endpoint does not cascade to downstream pipelines. Whether the downstream pipeline is a child pipeline (same project) or a multi-project pipeline, it remains running after the parent is canceled. Behavioral Explanation In GitLab (17.x), a trigger (bridge) job acts as the link between the parent and the downstream pipeline. When you cancel the parent pipeline, the bridge job is marked as canceled. However, once the bridge job has successfully triggered the downstream pipeline, that downstream pipeline exists as a distinct entity with its own unique ID. The API request to cancel a specific pipeline ID is scoped strictly to that ID; there is no recursive or cascade flag in the current REST contract. API Consumer Contract If your automation requires the entire pipeline tree to stop, you must implement a manual cascade. The intended workflow for API consumers is as follows: Cancel the parent pipeline. Retrieve the downstream pipeline IDs associated with the parent's bridge jobs (using the /bridges endpoint or pipeline details). Issue individual POST /cancel requests for each downstream pipeline ID. Note: For multi-project pipelines, the API token used must have the necessary permissions in the target project to execute the cancellation. Race Conditions: Timeout vs. Cancellation When a job timeout and a cancellation request occur simultaneously, the final status is nondeterministic. GitLab does not document a strict precedence rule for these events. Depending on which event is processed first by the coordinator, the job may be marked as failed (due to timeout) or canceled. Automation should be designed to treat both statuses as terminal and successful stops. Verification Steps To verify this behavior in your specific environment (SaaS vs. Self-Managed), you can run the following test: Create a parent pipeline with a bridge job that triggers a downstream pipeline with a long-running sleep job. Call the cancel endpoint on the parent pipeline ID. Poll the downstream pipeline status via GET /projects/:id/pipelines/:pipeline_id to confirm it remains in the running state.

Does GitLab Pipeline Cancel Cascade to Downstream Pipelines?

1 answer

Tasadduq BurneyownerOwner · Founder

35275 reputation · 30 Aug 2026, 15:29 UTC

Permalink

Cancellation Scope for Downstream Pipelines

Canceling a parent pipeline via the POST /projects/:id/pipelines/:pipeline_id/cancel endpoint does not cascade to downstream pipelines. Whether the downstream pipeline is a child pipeline (same project) or a multi-project pipeline, it remains running after the parent is canceled.

Behavioral Explanation

In GitLab (17.x), a trigger (bridge) job acts as the link between the parent and the downstream pipeline. When you cancel the parent pipeline, the bridge job is marked as canceled. However, once the bridge job has successfully triggered the downstream pipeline, that downstream pipeline exists as a distinct entity with its own unique ID. The API request to cancel a specific pipeline ID is scoped strictly to that ID; there is no recursive or cascade flag in the current REST contract.

API Consumer Contract

If your automation requires the entire pipeline tree to stop, you must implement a manual cascade. The intended workflow for API consumers is as follows:

Cancel the parent pipeline.
Retrieve the downstream pipeline IDs associated with the parent's bridge jobs (using the /bridges endpoint or pipeline details).
Issue individual POST /cancel requests for each downstream pipeline ID.

Note: For multi-project pipelines, the API token used must have the necessary permissions in the target project to execute the cancellation.

Race Conditions: Timeout vs. Cancellation

When a job timeout and a cancellation request occur simultaneously, the final status is nondeterministic. GitLab does not document a strict precedence rule for these events. Depending on which event is processed first by the coordinator, the job may be marked as failed (due to timeout) or canceled. Automation should be designed to treat both statuses as terminal and successful stops.

Verification Steps

To verify this behavior in your specific environment (SaaS vs. Self-Managed), you can run the following test:

Create a parent pipeline with a bridge job that triggers a downstream pipeline with a long-running sleep job.
Call the cancel endpoint on the parent pipeline ID.
Poll the downstream pipeline status via GET /projects/:id/pipelines/:pipeline_id to confirm it remains in the running state.

Your perspective belongs here.

Join the conversation

Canceling a parent pipeline: are downstream pipelines left running?