Monitor five things: how long jobs wait in the queue, how long a scan takes end to end, what share of scans succeed, how old the vulnerability data is, and what share of repositories are covered. Set a service level objective for each, because scanning failures are usually silent.
Why scanners need their own monitoring
A scanning platform can fail without anyone noticing. A pipeline step that errors but is set to continue, a database that stopped refreshing, a webhook that quietly stopped firing: all of these look like "no findings". Green dashboards with no scans behind them are worse than red ones.
Treat scanning as a service with users, and measure what those users experience.
The core indicators
| Indicator (SLI) | What it measures | Example objective |
|---|---|---|
| Queue age, by lane | Time between enqueue and start | Interactive jobs start within a few minutes at the 95th percentile |
| Time to first result | Enqueue to result visible to the developer | A target per scan type |
| Scan success rate | Completed over attempted, excluding user errors | A high percentage, with failure classes tracked |
| Data freshness | Age of the vulnerability database in use | Under a set number of hours |
| Coverage | Repositories and artifacts with a recent scan over those that should have one | A target, with the gap listed by owner |
| Dead-letter depth and age | Jobs that gave up | Zero older than a week |
The example objectives are placeholders. Choose numbers from your own baseline, publish them, and review them each quarter.
The one most teams miss: coverage
Success rate tells you whether scans that ran were good. It says nothing about the repositories that never ran. Build an inventory of everything that should be scanned from your source host and registries, then compare. New repositories are the usual gap: created last week, no pipeline yet.
Steps
- Emit structured events at each stage: enqueued, started, finished, failed, with job ID, lane, tenant, scan type, scanner version and database build.
- Compute the indicators from those events.
- Define an SLO for each, and an error budget so you know when to stop launching changes and fix reliability.
- Alert on symptoms, such as queue age over target, not on every worker restart.
- Add a synthetic check: a known vulnerable test artifact scanned on a schedule, which must produce a known finding. If it does not, the platform is broken even if everything looks healthy.
- Review the monthly numbers with the teams that depend on them.
Report outward too
Platform teams often keep these numbers private. Sharing a short monthly summary of coverage and freshness with engineering leadership builds trust and makes the case for capacity when it is needed.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how ongoing status is shown over time, which is the view your own indicators should give.
Safeguard's asset discovery helps find repositories and artifacts that should be scanned but are not. You can try the free scan at https://gold.safeguard.sh/scan.
Quick check
What is a synthetic check?
A scheduled scan of a known vulnerable test target that must return a known finding. It proves the whole path works.
Is a low failure rate enough?
No. Also measure coverage, because repositories that never got scanned produce no failures.
Last reviewed: 19 October 2026.
