Most teams do well with a monthly upgrade day for routine updates and an immediate path for urgent security fixes. Very small teams can go quarterly if tests are good. Larger groups often run it per service on a rotating schedule. Pick a cadence you will keep, since regular small upgrades hurt less than rare big ones.
Why a cadence beats ad hoc upgrades
Alerts arrive continuously, but your capacity to absorb change does not. A fixed upgrade day lets you batch low-risk updates, review them together, and keep the alert queue from absorbing every spare hour. It also makes the deferral decision honest: a dev-only or unreachable finding goes to the next upgrade day instead of into a forgotten dismissal.
Cadence by team size
| Team size | Suggested cadence | Why |
|---|---|---|
| 1 to 3 | Monthly, or quarterly with strong tests | Small surface, little coordination |
| 4 to 20 | Monthly, one rotating owner | Keeps batches small |
| 21 to 100 | Monthly per service, staggered | Avoids all teams upgrading at once |
| 100 plus | Per service schedule set by tier | Customer facing services more often |
These are starting points, not standards. Test coverage and release process matter more than headcount.
What the day looks like
- Open the list. Items deferred from alerts, plus pending update pull requests.
- Merge the grouped patch updates. GitHub supports grouping Dependabot updates so related bumps arrive together instead of one pull request per package.
- Handle minor versions one at a time. They are more likely to change behavior.
- Schedule majors separately. A major version bump is a project, not a chore.
- Review deferred dismissals. Anything past its review date gets a decision.
- Record what was skipped and why.
What never waits for upgrade day
A vulnerability listed in CISA's Known Exploited Vulnerabilities catalog and present in production should not wait. CISA strongly recommends all organizations review and monitor that catalog and prioritize listed items. Create an urgent path that skips the schedule: a named person, a short checklist, and a faster review.
Signs to change the cadence
| Sign | Change |
|---|---|
| Batches are huge and risky | Run more often |
| Upgrade day always gets cancelled | Run less often, or protect the time |
| Tests fail every time | Fix the tests before the cadence |
| Same package breaks repeatedly | Pin and plan a replacement |
Reduce the noise feeding the list
GitHub documents that auto-triage rules run before notifications are sent, that auto-dismissed alerts stay visible and reopenable, and that you can use a weekly digest. These let you deliver the upgrade day list without constant interruptions in between.
For a longer plan, see build a quarterly upgrade backlog from your SBOM and grouped pull requests reduce update fatigue.
Try it yourself
Click through it at your own pace, or open it full screen. Notice which findings already have a fixed version waiting.
Safeguard's SBOM and dependency scanning can show what is behind on upgrades, and its fix PRs are off by default with every category on Manual until you opt in. The free scan at gold.safeguard.sh/scan gives a starting list.
Quick check
Is quarterly too slow for dependency updates?
It can be fine for small, well-tested projects, as long as urgent security fixes have their own path.
Should every team upgrade on the same day?
Usually not. Staggering avoids shared dependency breakage landing everywhere at once.
Sources
- GitHub Docs, Dependabot auto-triage rules
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
Last reviewed: 19 October 2026.
