There is no magic number. Run as many checks as each one earns its place on speed, accuracy and a clear action. Many teams do well with a small required set and a larger optional or scheduled set. Prune any check that is slow, noisy or ignored.
Required, advisory and scheduled
Split checks into three tiers so a pull request is not carrying everything.
| Tier | Behavior | Examples |
|---|---|---|
| Required | Blocks merge | New vulnerable dependency, high confidence code rule, policy violation |
| Advisory | Comments or annotations, no block | Hygiene and style findings, medium confidence rules |
| Scheduled | Runs nightly or weekly, reports to owner | Full scans, container image rescans, license review |
A check moves between tiers based on data, not on opinion.
The entry test
A check earns a required slot only if it passes five questions.
- Fast. Does it finish in about the time of the unit tests, so developers do not wait on it?
- Accurate. Are most blocking results real?
- Scoped. Does it look at what the pull request changed?
- Actionable. Does each failure say what to do?
- Owned. Does someone maintain it and answer questions?
If any answer is no, start it as advisory.
The cost of one more check
Every added required check adds waiting time, extra failure modes, and one more thing to explain. Failures from different tools can also overlap, so a single issue appears three times. See deduplicate findings across scanners.
Flaky checks cost more than slow ones. A required check that fails at random teaches people to press re-run, and a re-run habit hides real failures. See flaky security tests and retries.
A starter set
For a typical service, a sensible starting point is:
- Required: dependency changes checked against known advisories, scoped to the diff.
- Required: a small set of high confidence code rules.
- Advisory: broader code rules, license findings, container base image notes.
- Scheduled: full repository scan, full image rescan, rule review.
Adjust for your risk. A payments service might require more. An internal tool might require less.
Prune every quarter
List all checks and fill in four columns: median run time, share of results dismissed, number of times it blocked a real problem, and owner. Move or retire the bottom performers. Retiring a check feels risky, so document the reason and the plan to cover the risk another way.
Watch the whole pipeline
Measure the total time from push to green, not just each check. If that grows month on month, you are paying a hidden tax. Run checks in parallel where you can, and cache scan inputs that have not changed. See caching scan results by digest and lockfile hash.
Do not forget the required status quirks
A required check that is skipped can still count as passed in some setups. Verify how your platform treats skipped or missing jobs.
Safeguard offers dependency scanning, code scanning and policy gates that can run on pull requests, with the CLI and IDE extensions for earlier feedback. The free scan at gold.safeguard.sh/scan shows a baseline.
Quick check
Is fewer checks always better?
No. Fewer checks that cover real risk beat many that people ignore, but dropping coverage without a replacement is a gap.
What if a check is slow but valuable?
Move it to a scheduled run or run it only on the paths it applies to, and keep a fast version on the pull request.
Last reviewed: 19 October 2026.
