Yes, on GitHub.com the version update configuration accepts a quarterly interval, along with daily, weekly, monthly, semiannually, yearly and cron. A quarterly cadence cuts review noise, but it produces large batches and delays fixes, so most teams pair it with a faster lane for security updates.
What the documentation says
GitHub's reference for its version update configuration file lists the supported schedule values as daily, weekly, monthly, quarterly, semiannually, yearly, or cron. Every package ecosystem entry must define an interval. Daily means every weekday, and weekly runs on Monday by default. The same page notes that the quarterly, semiannually and yearly values are only available on GitHub Enterprise Server from version 3.19, so check your hosting before you rely on them.
Check the current reference before you copy any config, because option lists change.
When a quarterly cadence helps
- Stable, low-exposure services. Internal tools with slow-moving dependencies do not need weekly pull requests.
- Teams drowning in noise. Fewer, larger pull requests can mean fewer interruptions.
- Aligned with a planning rhythm. If your team plans upgrades per quarter, one scheduled run at the start of the quarter feeds the backlog directly.
When it backfires
A quarterly run means each pull request is a batch of three months of changes. That has costs:
- A failing test is harder to attribute to one bump.
- Reviewers skim large diffs, which is the opposite of what a dependency change needs.
- A fix released the day after the run waits almost three months.
- Merge conflicts pile up while the branch sits.
Our post on batching upgrades versus shipping one at a time goes through the trade-off in more detail.
A hybrid that works for many teams
Split by purpose, not by tool setting:
| Lane | Cadence | What it covers |
|---|---|---|
| Security fixes | As soon as a fix exists | Reachable advisories and end-of-support deadlines |
| Routine patch and minor bumps | Monthly or weekly, grouped | Low-risk freshness |
| Major versions | Quarterly, planned by a person | Framework and runtime majors that need design time |
In this model, quarterly scheduling applies only to the third lane, where a human decides scope and timing anyway. Grouping rules in the config can bundle patch and minor updates into one pull request per ecosystem, which cuts noise without waiting a quarter.
How to set it up safely
- Decide the lanes above on paper first.
- Configure each ecosystem with the interval that matches its lane.
- Make CI fail loudly on update pull requests, so a green merge means something.
- Assign an owner for the scheduled run, because bot pull requests with no owner linger.
- After one quarter, count how many bot pull requests merged, closed or went stale, and adjust.
For guidance on what each bot pull request should satisfy before merge, see what a bot-opened upgrade PR needs before merge.
Where Safeguard fits
Safeguard's autonomous remediation can open fix pull requests for vulnerable dependencies. It is off by default, with every category set to Manual, so a person decides what is allowed. Scan a repository free at gold.safeguard.sh/scan.
Quick check
Does a quarterly schedule also delay security updates?
Version updates and security updates are configured separately on GitHub, but if you rely on the scheduled run alone for fixes, you will wait. Keep a faster path for advisories.
Is cron a better choice than quarterly?
A cron expression gives finer control, such as the first Monday of a quarter month. Choose it when the preset intervals do not match your planning calendar.
Sources
Last reviewed: 19 October 2026.
