There is no universal number, but a good working rule is to keep the checks that block a pull request short enough that developers wait for them, and move slow scans to a schedule or release stage. Set a budget per stage, measure it, and treat overruns as bugs.
Two paths, two budgets
| Path | When it runs | Typical contents | Budget idea |
|---|---|---|---|
| Fast | Every pull request | Dependency diff, secret scan on the diff, quick code rules | Minutes, in parallel with tests |
| Slow | Nightly, weekly or at release | Full code analysis, container image scan, dynamic tests | Longer, off the critical path |
Choose your own numbers from developer feedback. Ask what wait time makes people stop reading results or merge elsewhere, and set the fast path below that.
Techniques that cut scan time
- Scan the change, not the whole repo, for checks that support it.
- Run scans in parallel with tests rather than after them.
- Cache dependency metadata and scanner databases between runs.
- Skip scans when only docs changed, using path filters.
- Use a lockfile based dependency scan, which avoids building the project.
- Keep slow dynamic tests for a deployed preview or a scheduled run.
What not to cut
Do not remove the check just to hit a number. If the dependency scan is slow, fix the cache. If the code analysis is slow, move it to the slow path but keep a lighter rule set on pull requests.
Make timing visible
Add duration to your gate metrics. Report the median and the slowest ten percent per stage, per repo. A single repo with a huge monorepo may need its own settings rather than a global slowdown.
Decide the failure behaviour
A slow or flaky scan creates pressure to bypass. Decide up front whether a timed out scan blocks, warns or retries. See what happens when the scanner is down for the options.
Developer communication
Publish the budgets. When a scan breaches, open an issue in the platform backlog the same way you would for a broken build. Developers forgive a slow scan they can see being worked on.
Try it yourself
In the SAST demo, watch how scan scope and results are presented. Think about which parts belong on a pull request and which belong in a nightly run.
Click through it at your own pace, or open it full screen.
Quick check
Should full scans run on every pull request?
Only if they fit your budget. Otherwise run changed file checks on pull requests and the full analysis on a schedule.
Do nightly scans still protect us?
Yes, for issues that do not need a merge block, as long as someone owns the findings and the gate can still stop a release.
Safeguard supports scanning at pull request, build and scheduled stages, so teams can place each check where it fits the budget, and the free scan at gold.safeguard.sh/scan gives a quick sample.
Last reviewed: 19 October 2026.
