A lean routine is one 30 minute slot a week: check security alerts first, merge or close the bot pull requests that fit, decide whether anything needs a release, and write one line in a log. Everything else waits until next week.
Set the machine up once
The routine only works if the tools do most of the sorting. Do these once.
- Turn on Dependabot alerts and security updates for the repository.
- Add a version update config on a weekly schedule. Dependabot accepts intervals from daily to yearly, and a weekly run keeps your week predictable.
- Group routine updates. GitHub lets you combine updates into fewer pull requests with
groups, matched bypatterns,dependency-typeandupdate-types. By default, each outdated dependency gets its own pull request. - Cap the queue. The default is five open version update pull requests, and security update pull requests have a separate limit of 10.
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
groups:
dev-tools:
dependency-type: "development"
The 30 minutes
| Minutes | Task |
|---|---|
| 0 to 8 | Open alerts. Handle production dependency alerts before development ones, as GitHub recommends |
| 8 to 20 | Bot pull requests. Merge grouped dev updates when CI is green, review runtime ones |
| 20 to 25 | Decide: does any merged change justify a release? |
| 25 to 30 | Write the log line and close the tab |
Alerts. Filter with scope:development to see dev-only items and leave them for last. For each production alert, ask whether your code calls the vulnerable part. If you dismiss, add the comment. GitHub notes the comment shows in the timeline and helps with later audits.
Pull requests. A green CI run and a small change is the usual merge. A major version bump gets its own time, which may not be this week.
Release decision. A fix for an affected vulnerability means a patch release. A pile of routine bumps can wait for your normal release.
Log. One line in an issue or a file: date, what was merged, what was dismissed and why. It takes a minute and saves an hour when someone asks.
What to leave out
- Do not read every changelog. Read the ones for runtime dependencies that changed a major version.
- Do not chase every low severity finding in a dev tool.
- Do not run the routine when you are tired. Skip a week, and let the queue cap protect you.
When the week goes wrong
If an alert looks serious or a dependency is reported compromised, drop the routine and treat it as an incident. Otherwise the routine should feel boring, and that is the point.
Share it
If you have co-maintainers, rotate the slot. A rota of two people halves the load and removes the single point of failure.
Quick check
How many dependency pull requests should I allow open?
The Dependabot default is five for version updates. Lower it if reviewing feels heavy.
Is it fine to skip a week?
Yes, for routine updates. Security updates for code you call should not wait long.
Safeguard's reachability analysis can mark which findings your code actually reaches, which shortens step one. Try the free scan on a repository.
Sources
- GitHub docs, Dependabot options reference: https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference
- GitHub docs, viewing and updating Dependabot alerts: https://docs.github.com/en/code-security/dependabot/dependabot-alerts/viewing-and-updating-dependabot-alerts
Last reviewed: 19 October 2026.
