Cap open fix pull requests so the team finishes work before starting more. A limit stops bot floods, shortens review queues and makes progress visible. Start low, watch how fast pull requests close, and raise the limit only when the queue is clearing and reviewers keep up.
The idea in one paragraph
Work in progress limits come from lean and kanban practice: too many open items slow every item down, because attention is split. Fix pull requests behave the same way. Fifty open bumps mean fifty half read diffs, constant rebases and a reviewer who gives up. Ten open bumps get finished.
Limits update tools already have
Dependabot documents a default behaviour for version updates: if five pull requests are open, no new ones are raised until some are merged or closed. You can change the limit, or set a large value to effectively remove it. Security update pull requests are subject to a separate fixed limit of 10 open pull requests that the setting does not change. When either limit is reached, Dependabot reports an error and waits.
Renovate has comparable concurrency settings such as a limit on concurrent pull requests, and notes that other limits can be inherited from it. Check your tool's own documentation for the current defaults.
Choosing a starting limit
There is no universal number, so avoid copying one. Use this method:
- Count your reviewers who actually look at fix pull requests.
- Set the limit near the number that group can review in a normal week without strain.
- Watch the age of open pull requests.
- If the oldest stays young, raise the limit slowly. If pull requests age, lower it.
What the limit does for different roles
| Role | Benefit |
|---|---|
| Reviewer | Manageable queue, less context switching |
| Engineering leader | Clear signal when review is the constraint |
| Security lead | Fewer stale branches, cleaner aging data |
| CI owner | Predictable runner load |
Tune by class, not just by total
A single global limit can starve urgent work. Better to reserve room:
- A general limit for routine bumps.
- A separate lane for urgent, exploited findings that bypasses the routine cap.
- A small limit per repository so one noisy service cannot fill the whole queue.
Warning signs your limit is wrong
- Too high: the oldest open pull request keeps getting older, and reviewers batch approve without reading.
- Too low: findings with a fix sit unaddressed while the queue is nearly empty, and aging reports climb.
Review the limit monthly alongside your throughput numbers, as described in what remediation throughput is and how to measure it.
Do not hide the backlog
A cap on open pull requests is not a cap on findings. Keep the full list visible in your tracker so the unopened work still counts in your reports. Otherwise a tight limit makes the backlog look smaller than it is.
Where Safeguard fits
Safeguard's fix pull requests are off by default, and you set which categories may open them, so you control the inflow to your reviewers. Findings stay tracked whether or not a pull request is open.
Quick check
Does a pull request limit delay urgent fixes?
It can, if urgent work shares the same lane. Give urgent findings a separate path that is not held back by the routine cap.
Is a bigger limit always faster?
No. Past a point, more open pull requests slow review. Raise the limit only while the queue keeps clearing.
Sources
Last reviewed: 19 October 2026.
