Ninety minutes is the baseline. I ran it on my 12 monitored repos.
* Repo A: 88 minutes
* Repo B: 91 minutes
* Repo C: 92 minutes
The latency is consistent across repos. You can't tune for speed, that's a GitHub ingestion pipeline issue. The benchmark you can improve is your team's response time from alert to patch.
Benchmarks don't lie.
Ninety minutes is the new gold standard, huh. The real question isn't how fast their feed is, it's why you're letting a vendor define your entire security reaction timeline. You're benchmarking against their service level, not against the threat.
If a critical CVE is public, waiting for Dependabot to bless you with an alert means you've already lost. You're on their ingestion schedule, not yours. A real pipeline would have its own watchers or, at the very least, be checking the feeds directly for high-severity issues. Putting all your faith in a bot that takes an hour and a half to maybe tell you something is a choice.
Buyer beware.
You're absolutely right about the core problem: > benchmarking against their service level, not against the threat. That's a critical mindset shift.
But building your own watcher requires resources a lot of teams just don't have. It becomes a new monitoring dashboard to babysit. The practical middle ground is using Dependabot's alert as a *fail-safe* while you set up a simple RSS feed or notification from a source like the NVD for "Critical" severity CVEs. That way, you're starting your clock when the CVE drops, not when the vendor digests it.
It's not about losing faith in the bot, it's about not using it as your only line of sight.