Azure DevOps runs approvals and checks in five categories: static checks, pre-check approvals, dynamic checks, post-check approvals, then exclusive lock. Within each category they run in creation order. All checks on every resource a stage uses must pass before the stage starts, and one final negative decision fails the stage.
What approvals and checks are
Checks are controls attached to a protected resource, such as an environment, service connection, repository, variable group, secure file, or agent pool. They are not defined in the pipeline YAML. Microsoft's documentation points out that people editing the YAML cannot change the checks, because resource administrators manage them in the web interface. That separation is the main security value.
The five categories in order
| Step | Category | Examples |
|---|---|---|
| 1 | Static checks | Branch control, Required template, Evaluate artifact |
| 2 | Pre-check approvals | Approvals that are set to run early |
| 3 | Dynamic checks | Approval, Invoke Azure Function, Invoke REST API, Business Hours, Query Azure Monitor alerts |
| 4 | Post-check approvals | Approvals after the dynamic checks |
| 5 | Exclusive lock | Only one run proceeds at a time |
Static checks come first because they are cheap and deterministic. A branch that is not allowed fails immediately, before anyone is asked to approve anything.
Rules that surprise people
- A stage with several jobs, each using several resources, waits for every check on every resource.
- Checks are re-evaluated on the retry interval you set. If they have not all passed by the timeout, the stage does not run.
- For a manual approval, if a group is named, one member of the group is enough.
- The list of approvers is fixed when checks start. Editing the group afterwards does not change that run.
- A bypass is possible only for someone with administrator permission on the resource, and the checks panel records who bypassed.
- Decisions are final except for Invoke Azure Function or REST API checks that you configure with a non-zero time between evaluations, and for exclusive lock.
A practical check design
For a production environment, a layered design might be:
- Branch control set to the default branch, with branch protection required. Branch names must be fully qualified, for example
refs/heads/main. - Required template so the pipeline must extend your approved template.
- A manual approval from a group that excludes the person who wrote the change, using the option that restricts approvers from approving their own runs.
- An Invoke REST API check that waits for your security scan service to report on the artifact, if you have one.
- Exclusive lock so two deployments do not collide.
Microsoft's own FAQ gives the scan case: wait for an external scanning service by uploading the artifact where it can reach it and using an Invoke REST API check.
Try it yourself
Use the demo to see how a gate evaluates findings in order and returns one decision. Compare it with the check chain you just designed.
Click through it at your own pace, or open it full screen.
Quick check
Can a pipeline author remove a check by editing YAML?
No. Checks are configured on the resource through the web interface by its administrators, not in the pipeline file.
What happens if checks time out?
If all checks have not succeeded by the timeout, the stage is not executed. You can retry a stage when approvals and checks time out.
Safeguard policies and gates can supply the scan result that a REST API check waits for. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
