How to cancel a GitLab pipeline, and auto-cancel redundant ones

A stuck deploy, a pipeline started for the wrong commit, or three pipelines running because you pushed three times in a minute: sometimes the right move is to cancel. Here is how to cancel a GitLab pipeline or a single job in 2026, who is allowed to, and how to make GitLab cancel outdated pipelines on its own.

Cancel it by hand

• A whole pipeline: open the pipeline’s details page, the one with the job graph. From there you can cancel a running pipeline, retry failed jobs, or delete the pipeline.
• One job: open the job and cancel it from its page. Other running jobs carry on, but jobs in later stages, and jobs that list it in needs, are skipped.

A canceled job can be retried later, like a failed one. See how to retry a failed GitLab pipeline.

Who can cancel

By default, users with the Developer, Maintainer or Owner role can cancel pipelines and jobs; on a protected branch, they must also be allowed to push or merge to it. On Premium and Ultimate, a Maintainer or Owner can change that in Settings › CI/CD › General pipelines, under Minimum role required to cancel a pipeline or job: limit it to Maintainers and Owners, or prevent cancelling altogether.

From the command line and the API

• GitLab CLI: glab ci cancel pipeline 1504182795 cancels a pipeline, and glab ci cancel job 1504182795 a job. Both take several IDs, comma-separated or quoted, and --dry-run shows what would be canceled. For jobs in a protected environment, glab ci cancel job needs --force.
• API: POST /projects/:id/pipelines/:pipeline_id/cancel cancels all jobs in a pipeline; it returns 200 whatever the pipeline’s state. POST /projects/:id/jobs/:job_id/cancel cancels one job.

Cancel redundant pipelines automatically

When you push several times in a row, each push starts a pipeline, and usually only the newest matters. Auto-cancel redundant pipelines cancels the pending or running pipelines for older commits when a new commit’s pipeline starts on the same branch. It’s on by default; you’ll find it in Settings › CI/CD › General pipelines.

Which running jobs may be stopped is up to you. Mark the ones that are safe to stop halfway in .gitlab-ci.yml:

test:
  stage: test
  script:
    - make test
  interruptible: true

interruptible defaults to false. Under the default mode, GitLab cancels an older pipeline only while none of its non-interruptible jobs have started, so keep deploys and database migrations at the default.

Choose how aggressive auto-cancel is

workflow:auto_cancel:on_new_commit decides what happens when a newer commit arrives:

Value	What gets canceled
conservative (default)	The pipeline, but only if no job with interruptible: false has started yet
interruptible	Only the jobs marked interruptible: true; the others keep running
none	Nothing

Under the default, a single non-interruptible job that has started protects the whole pipeline from auto-cancel. If you’d rather stop the tests and let a running deploy finish, use interruptible:

workflow:
  auto_cancel:
    on_new_commit: interruptible

Stop everything when one job fails

workflow:auto_cancel:on_job_failure: all cancels the pipeline and all running jobs as soon as one job fails, so you stop paying for jobs whose result no longer matters. The default, none, lets them finish.

workflow:
  auto_cancel:
    on_job_failure: all

Cancel from your phone

A runaway job tends to show up when you’re away from your desk. In MergeBell, pipelines open with live job logs, and you can cancel a stuck job, retry a failed one or play a manual job, all on the free tier, using your own GitLab token and its permissions. With Pro, a pipeline watch sends a push when a pipeline on a branch you follow fails.