Measure advisory-to-alert time as the gap between an advisory's publication and the moment your team receives an alert for an affected project. Record three timestamps per finding, review the median and the slowest cases monthly, and fix whichever stage is slowest.
Why measure it
Teams usually know how often they scan. Few know how long they are exposed and uninformed. A nightly job can in theory be 24 hours behind. In practice the lag also includes the advisory source's delay, your poll interval and any batching of notifications.
GitHub notes that new vulnerabilities may take time to appear in its Advisory Database, so alerts can be delayed (about Dependabot alerts). That delay is outside your control, but you can see it in your numbers.
The three timestamps
| Timestamp | Where it comes from |
|---|---|
| Published | The advisory's own published date |
| Detected | When your system first matched it to a project |
| Alerted | When a human was notified |
From them you get three durations: source lag (published to detected, which includes your poll gap), processing lag (detected to alerted), and total.
Steps
- Add the fields. Store the advisory publish date and your first detection time on every finding.
- Add the alert time. Log when the notification was sent.
- Pick a sample. Take the last 30 days of new findings.
- Compute median and 90th percentile. The slow tail matters more than the average.
- Look for the biggest stage. If source lag dominates, shorten your poll interval or add a second feed. If processing lag dominates, look at batching or routing.
- Set a target. For example, urgent items alerted within hours, others within a day. Choose what fits your risk.
- Retest after changes.
Example log
| Finding | Published | Detected | Alerted |
|---|---|---|---|
| Example A | Mon 09:00 | Mon 09:40 | Mon 09:41 |
| Example B | Tue 14:00 | Wed 03:20 | Wed 08:00 |
Example A shows a fast poll with immediate paging. Example B shows a nightly detection and a morning digest, so about 18 hours elapsed. Both are made up for illustration.
Pitfalls
- Using detection time as publication time, which hides source lag.
- Averaging, which hides the worst cases.
- Counting only findings you acted on.
- Comparing across sources without noting that each publishes on its own schedule.
Quick check
What is a good target?
It depends on your risk. Many teams aim for hours on urgent classes and a day or less on the rest. Choose a number you can meet and then tighten it.
Does a faster poll always help?
Only if the source has the data. Polling more often than a source updates just adds load.
Sources
Last reviewed: 19 October 2026.
