Set the timezone explicitly, run updates in a quiet window outside working hours, and pick the day that gives you a full week to merge before your next release. Documented defaults differ between tools, so never rely on them. Use security fixes as the exception: they should not wait for the window.
Defaults you should not rely on
One bot's documentation says its schedules use UTC unless you set a timezone, and that a valid IANA time zone name is required. Another says that by default it randomly assigns a time to apply all updates in the configuration file, and you can set a specific time and timezone for all intervals. If you leave both alone, updates may arrive at hours that surprise your team, and a schedule written in local time may run hours off.
Two layers of schedule
The first bot separates a global schedule from a specific one. The global schedule decides when the tool itself runs, and for a self-run tool your administrator controls it. The specific schedule is the one in your repository, which decides whether the tool may look for updates for a dependency when it does run. An update happens only when both allow it. A repository schedule cannot make the tool run more often than the administrator configured, or at an exact minute.
How to choose a window
- Run outside office hours. The documentation lists this as a use case: it frees continuous integration for developers and cuts notifications during the day.
- Match your release rhythm. The noise guide gives the example of releases every Monday, so updates run Tuesday after midnight, leaving a week to test before the next release.
- Give yourself time to finish. Stale branches are rebased only when the tool runs inside the schedule, so a one-day window may strand conflicted branches.
- Use different schedules for different classes. Development tools can arrive daily, production frameworks weekly, and major versions monthly or on approval.
- Mind the syntax. The bot recommends five-part cron expressions, and says minute granularity is not supported, so the minutes field must be a wildcard.
| Class of update | A sensible cadence |
|---|---|
| Security fixes | Immediately, outside the window |
| Patch and minor, low risk | Weekly, off hours |
| Framework and runtime | Weekly or monthly, with review |
| Major versions | Monthly or by approval |
| Lockfile refresh | Weekly or monthly |
Distributed teams
If your team spans several timezones, an overnight window for one office is working hours for another. Pick the window by where CI capacity is free and where reviewers are, not by headquarters. Weekends are usually safe for the tool but a poor time for anyone to respond, so do not make merges depend on a weekend run.
Watch for silent failure
A schedule that never fires looks the same as a quiet week. Check that pull requests actually appear, and alert on a long gap. Our post on detecting a silently failing scheduled scan uses the same idea.
Quick check
Can I run the tool at an exact minute?
Not in the documentation we read for the first bot. It does not support minute granularity, and the global run frequency is set by whoever operates the tool.
Should security fixes follow the weekly window?
Usually not. Treat advisories as the exception and check how your tool schedules security pull requests.
Safeguard continuously monitors your dependencies against new advisories, so a quiet update window does not mean you stop looking. It builds an SBOM from manifests and lockfiles and uses reachability analysis to show which flagged packages your code calls. A free scan is available.
Sources
- Update bot documentation: scheduling
- Update bot documentation: noise reduction
- Code host documentation: update bot options reference, schedule
Last reviewed: 19 October 2026.
