A weekly update day batches changes and protects focus. Continuous updates shorten exposure and keep each change small. Most teams do best with a hybrid: continuous for security patches, a fixed weekly slot for everything else. Choose from your review capacity and how often advisories hit you.
The two approaches
Weekly update day. One day, or part of a day, each week is set aside to review and merge pending dependency updates. Everything else waits in a queue.
Continuous updates. Update pull requests are opened as new versions appear and merged as soon as checks pass and a reviewer approves.
Neither is right in general. The decision is about where you want the cost to land: in interruptions, in batch size, or in exposure time.
Compare them
| Factor | Weekly update day | Continuous |
|---|---|---|
| Review interruptions | Low, concentrated | Higher, spread across the week |
| Size of each change | Larger batch | Small, single purpose |
| When something breaks | Harder to find which update did it | Easy to find, easy to revert |
| Exposure to a new advisory | Up to a week of delay | Short |
| Reviewer fatigue | Peaks on the update day | Constant low level |
| Fits teams with | Slow CI, few reviewers | Fast CI, good test coverage |
The point about breakage deserves weight. Mixing ten updates into one pull request means a failure leaves you bisecting. Small independent changes fail in isolation.
Where security changes the answer
A weekly cadence means a patch for an exploited library can wait up to a week by default. For routine updates that is fine. For a vulnerability that is already being used by attackers, it is not. The CISA Known Exploited Vulnerabilities catalog lists such issues and attaches due dates for federal agencies, which is a reminder that exploited flaws carry a short clock.
So split by type. Security patches for reachable code go on the fast path. Feature updates, minor bumps with no advisory and cosmetic changes go to the weekly slot. If you need a rule for what jumps the queue, see auto-triage rules for dependency update pull requests at scale.
How to run a good weekly day
- Fix the day and time, and protect it on calendars.
- Rotate a single driver so the work does not fall on the same person.
- Merge in small groups with CI between them, not all at once.
- Cap the day. If the queue is still long, carry over and track the carry-over count.
- Write down any update that was skipped and why.
How to run continuous updates without the noise
- Group patch updates for related packages so they arrive together.
- Set a limit on open update pull requests per repository.
- Auto-merge only where tests are strong and the change is a patch.
- Assign a reviewer by rotation, not by whoever sees the notification first.
Fast checks matter more here, since every pull request costs a CI run. Related guidance is in dependency update triage strategy for engineering teams.
Measure and revisit
Track the age of the oldest open update and the share merged within a week. If many updates age past the cadence, the cadence is too slow for your team or the batch is too big. Re-evaluate every quarter.
Safeguard's SBOM and dependency scanning identifies which updates close known vulnerabilities, so you can route those to the fast path. Its fix pull requests are off by default and every category starts on Manual, so a person reviews each change either way.
Quick check
Is a weekly cadence too slow for security?
For routine updates it is usually fine. For an exploited, reachable vulnerability it is too slow, so keep a fast path for those.
Should we auto-merge update pull requests?
Only for low risk changes with strong tests, and only for patch level updates. Keep human review for anything with a larger version jump.
Sources
Last reviewed: 19 October 2026.
