PR Size Distribution
Track the size of pull requests across your organization and reduce deployment risk by keeping PRs focused.
Overview
PR size is one of the strongest predictors of deployment failure and long review cycles. Large PRs are harder to review, more likely to introduce bugs, and take longer to merge. Koalr's PR Size Distribution page gives you org-wide visibility into how large your PRs are — and shows you where to focus to drive them down.
How PR size is measured
Koalr measures PR size by total lines changed (additions + deletions):
| Size bucket | Lines changed | Risk level |
|---|---|---|
| XS | < 10 | Very low |
| S | 10–99 | Low |
| M | 100–249 | Medium |
| L | 250–499 | High |
| XL | 500–999 | Very high |
| XXL | 1,000+ | Critical |
Lines changed counts all file types. Auto-generated files (e.g., package-lock.json, migration auto-generated checksums) are excluded by default.
Why PR size matters
Research consistently shows:
- Reviewers find more bugs per line in small PRs. In PRs over 400 lines, reviewer attention degrades — bugs slip through.
- Cycle time scales with PR size. A 500-line PR takes 3–4× longer to review than a 100-line PR.
- Large PRs have higher deploy failure rates. Change entropy — which correlates with size — is the top predictor of post-deploy incidents (see Deploy Risk).
- Merge conflicts are more common in large, long-lived PRs. Each day a large PR stays open, it accumulates drift from the main branch.
Dashboard sections
Organization summary
- Median PR size — P50 lines changed across all merged PRs in the period
- % of PRs that are L or larger — the key metric to drive down
- Average review comments per PR by size bucket — shows reviewers engage less on large PRs
- Correlation: PR size vs. cycle time — scatter or bucketed bar chart
Size distribution chart
Histogram showing the count of merged PRs in each size bucket (XS through XXL) for the selected period. Compare against the prior period to see if your distribution is improving.
Team breakdown
Per-team median PR size and % of PRs that are L or larger. Platform/infrastructure teams often have larger PRs (config/migration heavy); product teams should trend smaller.
Top large PRs
Table of the largest PRs merged in the period, showing:
- PR title, author, repo
- Lines changed and size bucket
- Cycle time for that PR
- Link to GitHub PR
Size trend over time
Line chart of median PR size per week over 12 weeks. Upward drift = teams starting to batch work.
Setting size targets
Navigate to Settings → Work Configuration to configure:
- Team size targets — set a maximum recommended PR size per team (default: 250 lines)
- Alert threshold — get a Slack alert when a PR exceeds the threshold before merge
- Exclude patterns — glob patterns for files to exclude from line counts (e.g.,
*.lock,*.generated.*)
Reducing PR size
- Feature flags — merge incomplete features behind a flag; enables small, safe merges even for large features
- Vertical slicing — break stories into thin vertical slices that can be independently deployed
- Draft PRs — open PRs early as drafts to split large branches into reviewable chunks
- Stacked PRs — create dependent PR chains where each builds on the previous; tools like
gh stackor Graphite help manage this - Refactor separately — never mix refactoring with feature changes in the same PR
Relationship to other metrics
- Deploy Risk — large PRs and high change entropy are core risk signals (Deploy Risk)
- Cycle Time — the largest lever for reducing cycle time is reducing PR size (Cycle Time)
- Review Queue — large PRs clog review queues and increase reviewer overload (Review Queue)
- WIP Limits — enforcing WIP limits naturally pressures teams to keep PRs smaller to complete them faster (WIP Limits)