It might be. A weekly or monthly schedule is sensible for routine updates, but if it also governs vulnerability fixes, a flaw disclosed on Tuesday could wait until the next run. Check which settings apply to the security path in your bot, and test with a real alert.
Why schedules exist
Update bots create noise. Schedules, concurrency limits and PR creation rules keep that noise manageable. Teams set them once and forget them. The risk is that a setting meant for routine updates also catches the urgent ones.
What Renovate documents
Renovate's configuration reference has a vulnerabilityAlerts option, described as the config to apply when a PR is needed due to a vulnerability in the existing package version. The listed defaults include an empty schedule, prCreation set to immediate, a null minimumReleaseAge, no group name, and a concurrency limit of zero, which means no limit. The branch topic and a [SECURITY] suffix on the commit message mark these PRs. Renovate can read GitHub's vulnerability alerts for this, which requires the dependency graph and Dependabot alerts to be enabled.
The documentation also describes prCreation values. Immediate creates a PR as soon as the branch exists. Not-pending waits for status checks to complete. Status-success waits for tests to pass. Approval creates the branch immediately but waits for approval on the Dependency Dashboard to create the PR. Each is useful for routine work. For security fixes, an approval step adds a human wait, and a status-success rule hides a fix whose tests fail.
| Setting | Effect on a security PR |
|---|---|
| Empty schedule | Runs whenever the bot runs |
| prCreation immediate | PR appears at once |
| prCreation approval | Waits for a person on the dashboard |
| Concurrency limit | A low limit can queue the security PR behind others |
| minimumReleaseAge | Delays a new release if set for this path |
The vulnerability defaults above are the documented defaults. Your own configuration may override them, so read the effective configuration.
A test you can run
- Pick a recent advisory that affected a package you use.
- Note when the advisory was published and when the bot's PR opened.
- If the gap is more than one run of the bot, find the setting responsible: schedule, rate limit, approval or release age.
- Change it in the security block, not globally.
Also check how often the bot itself runs. A bot that runs once a day cannot open a PR within the hour.
Policies to write down
- Security PRs open immediately, outside any schedule.
- Security PRs are exempt from concurrency limits so they are not queued behind routine ones.
- Routine updates keep their schedule and cooldown.
- A named owner reviews bot configuration quarterly.
Related alert side delay
The bot depends on alert data. If the alerts feed is late, the PR will be late. That is covered in our post on when a dependency alert fires.
Try it yourself
Open the continuous monitoring demo to see how new findings appear after a build, which is the moment your bot should react.
Click through it at your own pace, or open it full screen.
Safeguard offers continuous monitoring and fix pull requests that are off by default. A free scan is available at gold.safeguard.sh/scan.
Quick check
Should security PRs follow the same schedule as other updates?
Usually not. Routine updates can batch. Security fixes are better opened as soon as they are available.
How do I confirm which settings apply?
Compare an advisory date to the PR open date for a recent case, then check the bot's effective configuration.
Sources
Last reviewed: 19 October 2026.
