Azure DevOps Services and Server · Branch policies · October 26, 2026

Azure DevOps pull request status checks: why a status policy waits, genre/name, and notApplicable

Services outside Azure Repos, such as a CI server, SonarQube or SonarCloud, or a security scanner, report on a pull request by posting a status to it. A Status checks branch policy then makes the pull request wait for one of those statuses. Below is how statuses and the policy work and why a status policy keeps waiting, from Microsoft's Customize and extend pull request workflows with pull request status, Available pull request status checks, Configure a branch policy for an external service and the REST reference for Pull Request Statuses.

What a status is

• State: one of succeeded, failed, error, pending, notSet or notApplicable. The web page shows a green check for succeeded, a red X for failed, a clock for pending and a red ! for error.
• Description: the text next to the icon, such as "Build in progress".
• Context: a genre (usually the service, such as continuous-integration) and a name, written genre/name. The web page shows it in a tooltip.
• Target URL: when given, the description becomes a link to the service's page about the result.
• A service updates its result by posting a new status with the same context. Only the latest status of each context is shown, so pending, then succeeded or failed, is the usual sequence.

Iteration status

• Every push to the source branch makes a new iteration of the pull request. A status can be posted to a specific iteration, so that it applies only to the code that was evaluated, or to the pull request as a whole (for a check that does not depend on the code, such as who the author is).
• When a status checks code, Microsoft recommends setting the policy's Reset conditions to Reset status whenever there are new changes, so the pull request cannot be completed until the latest iteration has a succeeded status.
• A pull request with more than 100,000 changed files has no iterations, and posting a status to an iteration that does not exist returns an error.

The Status checks policy

• In the branch's Branch policies, under Status checks, select +. In Status to check, pick a status that was posted before, or type genre/name for a service that has not posted yet.
• Policy requirement: Required needs a succeeded status with that context to complete the pull request. Optional is only informational.
• Authorized identity: only statuses posted by this account count. Leave it blank to accept any account.
• Reset conditions: whether a new push makes the posted status stale (above).
• Policy applicability: Apply by default applies from the moment the pull request is created, so it does not pass until a succeeded status arrives. Conditional applies only after the first status is posted.
• Path filter (optional) and Default display name (optional), as with the other branch policies.
• Setting status policies takes the Edit policies permission, or membership in Project Administrators.

Why the status policy is still waiting

• The service has not posted yet. Until then a new policy shows as not set. A pending or notSet status also keeps a required policy waiting; failed and error block it.
• The context does not match. The policy needs a status with exactly its genre/name. A value typed by hand for a service that has not posted yet is the easiest one to get wrong.
• Another account posted it. With an Authorized identity, statuses from any other account do not count.
• A new push reset it. With Reset status whenever there are new changes, the earlier succeeded status no longer counts until the service posts for the latest code.
• The check does not apply to this change. With Apply by default, the service (or a script) can post notApplicable: it lifts the requirement for that one pull request without changing the policy.

Checks Azure DevOps posts itself

• GitHub Advanced Security for Azure DevOps posts AdvancedSecurity/AllHighAndCritical (any unresolved critical or high alert in the repository) and AdvancedSecurity/NewHighAndCritical (only those the pull request adds). Both need a build validation policy with the Advanced Security tasks; Microsoft says to leave the policy's advanced options at their defaults for them.
• Azure Pipelines code coverage posts {pipeline name}/codecoverage with the diff coverage of the lines the pull request changes (70% by default, set in azurepipelines-coverage.yml).
• Every other status comes from an outside service through the REST API: CI servers such as Jenkins, code quality tools such as SonarQube and SonarCloud, security scanners, approval services.

Posting and reading statuses with the REST API

• POST …/_apis/git/repositories/{repositoryId}/pullRequests/{pullRequestId}/statuses?api-version=7.1 with state, description, context (name, genre) and targetUrl posts a status; an iterationId ties it to an iteration. The token needs Code (Read & write) or Code (Status), and the account the Contribute to pull requests permission.
• GET on the same address lists every status posted, with Code (Read).
• The resource was released in REST 7.0 (Azure DevOps Server 2022). Older servers have it as a preview, back to 4.1 (TFS 2018 Update 2): ask it with api-version=6.0-preview.1 and so on.

Status checks in IntelliJ IDEA

Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, lists the pull requests of Azure DevOps Services and Azure DevOps Server in an IDE tool window with their branch policies in plain words: a Status checks policy shows its genre/name and whether it passed, failed or is waiting. From version 1.0.61 the Overview also shows the statuses other services posted, the latest for each context, problems first, with the description linking to the service's page, as the web page's status section does. The review inbox, the branch policies and the statuses are free; voting, commenting, completing and creating pull requests are Pro, with a 30-day trial.

Get it on JetBrains Marketplace

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

More: build validation and expired builds · auto-complete and optional policies · required reviewers and path filters · explicit override to bypass policies · 日本語