Pull request scans check what a change introduces. Scheduled scans check the whole estate against new information. They run at different times, on different scope, with different owners, so their metrics must be kept apart. Mixing them gives scan times and failure rates that describe nothing real.
Two jobs, two questions
| Pull request scan | Scheduled scan | |
|---|---|---|
| Question | Does this change add risk? | Has anything we already shipped become risky? |
| Scope | Changed files and dependencies | Whole repository or image |
| Trigger | Push or pull request event | Timer |
| Who waits | A developer | Nobody, usually |
| Who acts on results | The author | Owning team via a ticket or alert |
| Fails what | A merge | A report or a ticket |
Because they differ so much, one set of numbers for both hides everything.
What goes wrong when mixed
- Scan time. A long scheduled scan drags up the percentile for pull request scans that developers actually wait on.
- Failure rate. Scheduled scans find old debt, so failure rates look high, even when pull requests are clean.
- Findings per run. Scheduled scans see the whole backlog, so counts balloon compared with pull requests.
- Coverage. A repository might be scanned on a schedule but never on pull requests, and a mixed number says it is covered.
How to separate them
- Tag every run record with its trigger: pull request, merge, release, scheduled or manual.
- Report each trigger type as its own series for timing, outcome and findings.
- Define coverage per trigger: share of repositories with pull request scans, and share with scheduled scans.
- Give each series an owner. Pull request scan speed belongs to the platform team. Scheduled scan findings belong to the owning service teams.
Metrics worth keeping for each
For pull request scans: time to first feedback, queue and run time, block rate, re-run rate and time to unblock.
For scheduled scans: completion rate, age of oldest finding, new findings from advisories published since the last run, and how many tickets opened versus closed.
The link between them
The two should feed each other. A new advisory found by a scheduled scan should become a policy that pull request scans enforce, so the same problem is not added again. Track how often a scheduled scan finds something a pull request scan could have caught. That number points at gaps in the gate.
Quick check
Is a post-merge scan a pull request scan?
Treat it as its own trigger type, since it runs after the merge and nobody waits on it in the same way.
Do I need both kinds?
Usually yes. Pull request scans stop new risk, and scheduled scans catch risk that arrives after shipping, such as a newly published advisory.
How Safeguard fits
Safeguard offers dependency and SBOM scanning with policy gates for changes and continuous monitoring for what has already shipped. You can try a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
