There is no standard number, so treat any figure as a planning heuristic. A solo developer might reserve fifteen minutes a week, a small team an hour for one rotating owner, and larger groups a shared review plus a few hours of owner time. Set a budget, measure it for a month, then adjust.
Why a budget helps
Without a budget, triage expands to fill whatever time anxiety gives it, or it shrinks to nothing when deadlines hit. A fixed block makes the work visible, gives you something to defend in planning, and shows when the problem has outgrown the time.
The figures below are starting points for discussion, not measured industry data.
Starting points
| Team size | Triage owner time | Group time | Notes |
|---|---|---|---|
| 1 to 3 | 15 to 30 minutes | None | One fixed slot a week |
| 4 to 10 | 1 to 2 hours | 10 minute handover | Rotating weekly owner |
| 11 to 50 | 2 to 4 hours per owner | 30 minute review | Per-team owners |
| 51 to 200 | Part of one role per team | 30 minute leads review | Central group audits |
| 200 plus | Dedicated roles | Business unit reviews | Policy and exceptions governance |
How to set your own number
- Measure for four weeks. Log minutes spent reading, deciding, and fixing alerts. Include interruptions, which are the hidden cost.
- Separate triage from fixing. Triage is deciding. Fixing is engineering work and belongs in sprint planning.
- Count the decisions. Divide minutes by alerts to get a per-alert cost. If it is high, automation will pay back sooner.
- Pick a budget. Aim slightly below your measured average, then remove work to meet it.
- Review monthly.
Where the time goes
Most triage minutes go to reading alerts that did not need a decision. Reducing those is the best lever.
- Control notifications. GitHub documents that auto-triage rules apply before notifications are sent, and that weekly digests are available.
- Use outside signals to order work. CISA recommends all organizations prioritize its Known Exploited Vulnerabilities catalog, and FIRST publishes EPSS exploitation probabilities daily. Both let you sort first and read second.
- Group duplicates. One advisory across repositories should take one decision. See one fix, many alerts.
Signs the budget is too small
- Alerts regularly age past their window.
- The owner works through lunch to catch up.
- Dismissals have no reasons because there was no time to write them.
- Known exploited items are noticed by accident.
When two or more show up, the answer is either more automation, less scope, or more time. Do not quietly accept all three failing at once.
Signs it is too large
If an owner spends hours on alerts that are always dismissed, the rules are too loose upstream. Tune them. See retire, tune, or automate a noisy alert.
Try it yourself
Click through it at your own pace, or open it full screen. Count how many items would still need a human decision after the filter.
Safeguard's reachability analysis and policies are built to shrink that decision count, and the free scan at gold.safeguard.sh/scan lets you try it on a real repository.
Quick check
Is an hour a week enough for a team of ten?
It can be, if ownership, notifications, and rules are in place. If alerts are aging, the budget or the rules need work.
Does triage time include writing the fix?
Count them separately. Triage is the decision. The fix is planned engineering work.
Sources
- GitHub Docs, Dependabot auto-triage rules
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
- FIRST, EPSS
Last reviewed: 19 October 2026.
