There is no universal threshold, and we will not invent one. The practical answer is to set a time budget for each stage with your own developers, measure real runtimes, and move anything that exceeds the budget to a later stage. A scan that people work around protects nothing.
Why speed is a security property
A control that people avoid is not a control. When a required check takes long enough that developers context switch away, they start batching changes, merging larger pull requests, and asking for overrides. Each of those makes review worse.
Speed matters differently at each stage:
| Stage | What the developer is doing | Tolerance |
|---|---|---|
| IDE | Typing | Near instant |
| Pre-commit | About to commit | A few seconds |
| Pull request | Waiting for review anyway | Minutes, in parallel with review |
| Scheduled | Not waiting | Much longer |
The pull request check has the most room, because a reviewer usually takes longer than the scan. The IDE and commit stages have almost none.
Set a budget, then measure
- Ask developers what delay they accept at each stage. Write the answers down.
- Record the actual runtime of each check for a few weeks, including queue time.
- Look at the slow tail, not only the average. A check that is usually quick and sometimes very slow trains people to expect the slow case.
- Compare the numbers with the budget.
What to do when a check is too slow
- Scope it to the change instead of the whole repository.
- Cache dependency data between runs where your platform supports it, taking care with shared caches on privileged workflows.
- Run independent checks in parallel.
- Move it to a later stage, such as release or a scheduled job.
- Make it asynchronous: report a result later and block only at the release gate.
Caching deserves a caution. GitHub's hardening guide notes that privileged workflows share the main branch cache, so do not let untrusted runs write caches that privileged runs will trust.
Warning signs that people are working around you
- Rising use of administrator overrides.
- Pull requests that bundle many changes to avoid repeated waits.
- Requests to disable a check "just for this release."
- Suppression comments appearing in bulk.
Any of these is a signal to look at speed and noise before you look at people.
Report the cost back
Publish the runtime of security checks the same way you publish test runtime. When developers can see that security adds a measured two minutes and not an unknown wait, the discussion becomes concrete.
Where Safeguard fits
Safeguard's reachability analysis reduces noise, and its CLI and IDE extensions give fast local results while pull request gates handle the shared check. A free scan is at https://gold.safeguard.sh/scan.
Quick check
Is there a standard scan time limit?
No widely accepted one. Set a budget with your own developers by stage and measure against it.
Should slow checks be removed?
Not removed, moved. Put them at a stage where waiting costs less, such as release or a scheduled run.
Sources
Last reviewed: 19 October 2026.
