Detect a silently failing scan by watching for the absence of success, not the presence of errors. Have each run send a heartbeat when it finishes, and alert if no heartbeat arrives within the expected window. Also check that results are not suspiciously empty.
Why scans fail quietly
A failing scan that sends an error email is the easy case. The dangerous ones send nothing:
- The schedule was disabled, so no job ever starts.
- The person who owned the job left, so failure notices go to nobody.
- An access token expired, and the job exits early with a log line nobody reads.
- The scanner ran but found zero packages, because a path changed.
- The advisory data source was unreachable, and the tool fell back to old data.
In each case the dashboard stays green or simply stops updating. People read that as good news.
The heartbeat pattern
A heartbeat is a small signal sent only on success. A dead man's switch watches for it. If the signal is late, the switch fires.
- Pick the expected window. A nightly job gets a 26 hour window to allow for delays.
- Send a ping at the end of a good run. Only after the scan completes and the results upload succeeds.
- Alert on silence. The alert goes to a team channel or on call rota, not to one person.
- Test it. Disable the job on purpose once and confirm someone is told.
Checks inside the run
| Check | What it catches |
|---|---|
| Package count above a floor | Wrong path, empty lockfile, skipped ecosystem |
| Advisory data timestamp is recent | Stale or unreachable data source |
| Exit code and upload status both good | A scan that ran but never reported |
| Run duration within a normal band | A job that exits in two seconds |
Set the package count floor from history. If a service normally reports 340 packages and today reports 4, fail the job and say why.
Fix the ownership problem
Failure notices from a scheduled CI job often go to whoever created it or last edited it. GitHub documents this for scheduled workflows (notifications for workflow runs). GitLab ties a pipeline schedule to its owner and notes that a schedule can become inactive if that owner is blocked or removed (GitLab pipeline schedules). Use a service account or a shared owner, and record who is responsible for the job.
Review the list of scheduled jobs each quarter. If one has no owner, assign one or retire it.
Where Safeguard fits
Safeguard offers SBOM and dependency scanning and policy gates. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a green dashboard proof the scan ran?
No. A dashboard shows the last results it received. Check the timestamp of the last successful run.
What is a sensible alert window for a nightly scan?
Around 26 hours. That absorbs normal delays but still flags a missed night before the next one.
Sources
Last reviewed: 19 October 2026.
