Azure Pipelines · Checked November 4, 2026

Azure Pipelines: why a run is still running after you cancel it (conditions, the cancel timeout, and Force cancel)

Cancel in Azure Pipelines does not stop everything. It stops what would run only after a success, and lets anything whose condition is still true go on: a stage, job or step with condition: always(), or with a condition such as eq(variables['Build.SourceBranch'], 'refs/heads/main') that does not look at the run state. Microsoft's answer to "Why is my build still running after I canceled it?" is to add a job status check function to the condition (Pipeline conditions). Since the Sprint 281 update of October 27, 2026, a run that still does not stop can also be force-cancelled.

What Cancel stops, and what it does not

A run cancelled while it waits in the queue, before anything has started, is cancelled whole, with all its stages.
With no condition, a stage, job or step has the default, succeeded(), so it does not start after a cancel.
succeededOrFailed() runs after a failure but not after a cancel. always() runs after both.
A condition you write replaces the default. If it uses none of succeeded(), failed(), succeededOrFailed() and canceled(), the cancel makes no difference to it: in Microsoft's examples, a stage, a job or a step with only eq(variables['Build.SourceBranch'], 'refs/heads/main') still runs when a run on main is cancelled while something before it is running.
What is inside a skipped parent does not run, whatever its own condition says. A job with that main condition, in a stage that depends on the cancelled one, is skipped with its stage.

Write conditions that stop on Cancel

Put a status function in next to your own test:

- stage: Deploy
  condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

For clean-up that should run after a failure but not after a cancel, use succeededOrFailed() (or and(succeededOrFailed(), ...) with your own test). Keep always() for steps that must run even after a cancel, and give them a cancel timeout.

How long the steps that go on get

After a cancel, a job gives the steps that still run its cancelTimeoutInMinutes: 5 minutes when you do not set it, from 1 to 35,790. Then they are stopped. On Microsoft-hosted agents, the longest a job can run still applies (Jobs in Azure Pipelines, Timeouts):

jobs:
- job: Deploy
  timeoutInMinutes: 60
  cancelTimeoutInMinutes: 2

Force cancel (Sprint 281)

For a run that goes on because of such a condition, the Sprint 281 update of October 27, 2026, which Microsoft rolls out over two to three weeks, adds a force-cancel option to the run, with a confirmation:

It stops every running stage, job and step at once, and nothing after them runs. Microsoft warns that this can leave your system in an inconsistent state.
The run is abandoned and cannot be run again.
It needs three pipeline permissions: Manage stage run order, Stop builds and Abandon builds.

Fixing the condition is still the lasting answer: Force cancel stops one run, and the next cancel of the same pipeline behaves as before.

Abandon a run that has ended

The same update lets you abandon a run that has ended, Failed or Canceled for example, from the run's menu. An abandoned run is read-only, so none of its stages can be run again, which keeps a wrong artifact from being deployed again. It needs the Abandon builds permission and cannot be undone.

Telling it apart

The stages, jobs or steps that went on after the cancel have a condition of their own in the YAML, with no status function in it; the ones that stopped have no condition, or one with succeeded(). A template can bring such a condition in, so look at the templates the stage or job comes from too.

Build validation in IntelliJ IDEA and Rider

Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists your pull requests in an IDE tool window with their branch policies in plain words, so a build policy that failed shows up next to its pull request. With Pro, a build that failed or expired has a Run again link that queues it again. The review inbox and the branch policies are free; voting, commenting, completing, running a build policy again and creating pull requests are Pro (US$1 a month, with a 30-day trial).

Get it on JetBrains Marketplace

Azure DevOps is a trademark of Microsoft Corporation; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft or JetBrains.

More: build validation: expired builds, manual queue, and why a pull request build did not run · "Access to the path '/home/vsts' is denied" on Ubuntu 26.04 · the same question in GitHub Actions · 日本語