A passing Azure DevOps build validation goes stale only if you tell it to. The build expiration setting offers three choices: expire immediately when the target branch updates, expire after a number of hours, or never. "Never" is the default risk, because a pull request can merge on a build that predates the current branch.
What build validation does
A build validation policy queues a pipeline run for a pull request and checks the result before the pull request can complete. The trigger can be Automatic, which runs whenever the source branch is updated, or Manual. The policy requirement can be Required, where the build must succeed to complete the pull request, or Optional, where a failure only notifies.
That much is familiar. The less visible part is what happens to a green result when the target branch moves on.
The three expiration options
| Option | Behavior | Best for |
|---|---|---|
| Immediately when the branch is updated | Marks the policy failed and requeues a build every time the target changes | Quiet branches with few updates |
| After a set number of hours if the branch has been updated | Expires the status when the target changed and the passing build is older than the threshold | Busy branches, as a compromise |
| Never | Branch updates do not change the policy status | Fewest builds, most stale results |
Microsoft notes that "Never" reduces the number of builds but can cause problems when completing pull requests that were not updated recently. In plain terms, two pull requests can each pass in isolation and still break the branch when both merge.
Why this is a security question
Security checks often run inside that build: dependency scanning, static analysis, secret detection. If the build result is stale, the check ran against old code and an old dependency set. A new advisory, or a change merged to the target branch an hour ago, is not reflected.
How to choose
- Mark build validation Required on the default branch.
- Use Automatic trigger so developers do not have to remember it.
- For low traffic repositories, choose immediate expiration.
- For busy repositories, choose a threshold in hours that matches how fast your branch changes, and pair it with a merge queue style habit of rebasing before completion.
- Avoid "Never" on any branch that deploys.
- Add a path filter only if you are sure the paths cover everything the build depends on, including lock files.
Related settings
A status check policy lets an external service post results to the pull request. It also has reset conditions, so the same stale result question applies to checks that do not run inside your pipeline.
Try it yourself
Click through the demo below and follow how a pull request gate decides to block or allow a change. Then think about how old the scan result behind that decision is in your own process.
Click through it at your own pace, or open it full screen.
Quick check
Is build validation required by default?
You choose. The policy requirement is either Required or Optional. Only Required blocks completion on a failed build.
Which expiration option runs the fewest builds?
Never. It also carries the most risk of merging on a result that predates the current target branch.
Safeguard can run dependency scanning and policy gates on pull requests, so the check that decides a merge is based on current advisory data. You can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
