What Are Pull Request Throughput?
The number of pull requests a team merges into the main branch per time period (day, week, or sprint). A direct measure of engineering output and delivery cadence.
2-minute setup • No credit card required
What it means
Pull request throughput counts how many PRs are reviewed, approved, and merged in a given timeframe. It's one of the most straightforward engineering metrics because it's directly observable from git data — no estimation or subjective scoring required. Throughput is distinct from velocity (which uses story points) because it counts units of work delivered regardless of size. A team merging 15 PRs per week is shipping 15 discrete changes, each of which went through the full review and CI process. High throughput with small PRs is the ideal: it means the team is shipping frequently in small batches, which aligns with Lean principles and DORA best practices. Throughput is typically measured per team per week, and trends over time reveal capacity changes and process bottlenecks.
Why Pull Request Throughput matter
Pull request throughput is the simplest answer to 'how much is the team shipping?' that doesn't require subjective estimation. It's particularly useful for engineering managers who want to spot trends: a drop in throughput might indicate blocked reviews, team members pulled into meetings, unclear requirements, or a difficult technical problem. For reporting to non-technical stakeholders, 'the team merged 48 PRs this sprint' is concrete and understandable. Throughput also helps validate process changes — if you introduce a new review policy and throughput drops 30%, the policy might be too burdensome. Combined with PR size data, throughput gives a complete picture of delivery flow.
How to measure
Count merged PRs per team per time period from your git platform (GitHub, GitLab, Bitbucket). Most platforms have APIs or built-in analytics for this. Include all merged PRs: features, bug fixes, refactoring, and documentation. Exclude automated PRs (Dependabot, Renovate) unless you want to track them separately. Track weekly for operational decisions, monthly for trend analysis. Also track PR size (lines changed) alongside throughput — a team merging 20 tiny PRs and a team merging 20 large PRs have very different dynamics.
Real-world example
A 6-person team tracks their weekly PR throughput over a quarter: weeks 1-4 average 22 PRs/week, weeks 5-8 drop to 14 PRs/week, weeks 9-12 recover to 20 PRs/week. Investigating the dip: two senior engineers were pulled into architecture planning for 3 weeks, and the remaining developers had more PRs waiting for review (review queue grew). The team introduces a daily review rotation so no PR waits more than 4 hours, and throughput stabilizes at 24 PRs/week even when team members are occasionally pulled into other work.
Related terms
Common questions
What is a good pull request throughput?
It depends on team size and PR granularity. A rough benchmark: 3-5 merged PRs per developer per week indicates healthy flow. A 5-person team should be merging 15-25 PRs per week. Below 2 PRs per developer per week suggests bottlenecks; above 7 might indicate PRs are too small to be meaningful or include automated PRs.
Does higher PR throughput mean higher productivity?
Not necessarily. Throughput measures output quantity, not quality or impact. A team could merge 30 trivial PRs or 10 high-impact PRs. Throughput is most useful as a flow metric — it tells you whether work is moving through the pipeline smoothly. Combine it with business metrics (features shipped, bugs resolved) for a complete picture.
Should you count automated PRs in throughput?
Track them separately. Dependabot, Renovate, and other automated PRs inflate throughput numbers without representing team output. Most teams report two numbers: total throughput (including automated) and human throughput (excluding automated). Human throughput is the metric that reflects team capacity.
How does PR size affect throughput?
Smaller PRs generally lead to higher throughput because they're faster to review, less likely to have merge conflicts, and easier to test. Research from Google shows that PRs under 200 lines get reviewed 15x faster than PRs over 1000 lines. If your throughput is low, check whether PR size is the bottleneck.
Track Pull Request Throughput Automatically
Gitmore turns your git activity into automated reports with real metrics — delivered to Slack and email.
Get Started FreeNo credit card • No sales call • Reports in 2 minutes