Review Capacity Report
Last updated: October 27, 2026
The Review Capacity report shows how pull request (PR) review work is spread across your teams and reviewers, how evenly each team shares it, and how much of each team's review effort goes to other teams' PRs.
Why it matters
As AI tools help engineers produce more, and often larger, PRs, code review becomes the new bottleneck. Review bots help, but people still carry the responsibility for code quality and correctness. This report focuses on that human side: whether review load is sustainable, concentrated on a few people, or pulled away by cross-team demand. It answers questions like:
Is review work spread evenly across my team, or concentrated among a few reviewers?
How much of my team's review capacity goes to other teams' PRs?
Which team pairings create the most cross-team review demand?
How dependent is my team on one or two reviewers?
Is review load keeping pace as development speeds up?
How it works
Review weight is Span's effort score for one reviewer on one PR. It grows with the PR's complexity, the number of review rounds, and the substantive comment threads the reviewer took part in, and it shrinks when several reviewers share the PR:
raw = (1 + 2 × complexity) × (1 + 0.5 × (min(rounds, 8) − 1)) × (1 + ln(1 + thread score)) ÷ √(number of reviewers)
weight = 0.25 + 2.75 ÷ (1 + (3.5 ÷ raw)²)Complexity (0.1 to 1.0) comes from an AI score of the PR's size-independent complexity, from 1 to 10, divided by 10. Until a PR has a score, Span estimates from its size.
Rounds are the reviewer's separate review sessions on the PR. Reviews less than 20 minutes apart join one round. Span caps rounds at 8.
Thread score adds 1.0 for each actionable thread, 0.5 for a thread with a review theme or one not yet analyzed, 0.25 for a nitpick, and 0 for threads with no theme, such as "LGTM".
The final weight always falls between 0.25 and 3.0. Span dates it to the reviewer's first review on the PR.
Columns in the team table:
Column | What it shows |
|---|---|
Members | Unique people in the team and its sub-teams |
Review weight / member | The team's total review weight in the date range divided by members |
Avg. load balance | How evenly the team shares review weight, from 0 to 100 |
Intra-team % | Share of the team's review weight spent on PRs authored by the same team |
Cross-team % | Share of the team's review weight spent on PRs authored by other teams |
Load balance is 100 × (1 − Gini coefficient of review weight) across the team's active developers, computed each week and averaged over your date range. 100 means everyone carried the same review weight. Members with no review weight that week count as zero. Colors: 50 or above green, 25 to 49 neutral, below 25 red.
The team drawer lists each reviewer's Review weight, Team load % (their share of the team's weight), and their own intra-team and cross-team split, plus the authoring teams that used the team's capacity.
Setup
Go to Insights → Productivity → Quality → Review capacity. At the top of the report:
Control | Description |
|---|---|
Date range | Any custom time window |
Team / group filter | Scope the report to a team, a group, or the whole organization |
Group teams by | The hierarchy level to aggregate teams at, for example Squads, Level 1, or Level 2. Defaults to Squads |
All / Cross-Team | Cross-Team counts only weight from reviews of other teams' PRs |
Things to know
Worked example (weight): a reviewer gives two rounds of review on a PR with complexity 5 (0.5), joins one actionable thread and one nitpick (thread score 1.25), and shares the PR with one other reviewer. Raw = 2 × 1.5 × 1.81 ÷ 1.41 = 3.84, which normalizes to a weight of about 1.75.
Worked example (balance): on a team of four where everyone carries 10 weight in a week, the score is 100. If one person carries all 40, the score is about 25.
Hidden teams: the page hides teams with fewer than 3 members, or with less than 2 review weight per week over the range. Teams with fewer than 3 active developers get no load balance score.
Intra-team is decided at the level you pick: a review is intra-team when reviewer and author belong to the same team at the selected hierarchy level. This can differ from the Cross-Team toggle on the Code review pages, which uses the whole team tree.
Members in several teams: multi-team membership changes totals and ratios. Deflation: reviewer X in teams A and B reviews author Y in A and C. Only the A to A pair counts as intra-team; the B to C pair drops, so it's missing from team B's totals and X's totals within B. Inflation: reviewer X in A and B reviews author Y in C and D. Span counts four pairs (A to C, A to D, B to C, B to D), each with the full weight, so one review counts four times across teams. Net effect: intra-team reviews weigh less in the totals, and cross-team reviews between multi-team members are amplified.
People only: coding agents and unmapped accounts carry no weight. Reviews of PRs whose author isn't a mapped person drop out of team totals; the drawer notes how much weight it excluded.
Ignore lists don't apply: reviews on repositories or branches you ignore in Settings → Metrics still add weight here.
Current membership: Span uses today's team roster for past weeks, so past scores change after a reorg.
Range length matters: Review weight / member is a total over the whole date range, so a longer range shows a bigger number.
Fresh PRs: weight can shift after the AI scores a new PR's complexity and threads, usually within hours.
Not on custom dashboards: Review Capacity metrics are available on this page only.
Common uses. Low load balance scores show review work concentrated on a few reviewers; open the team drawer to see who carries it. Watch the load balance trend chart to check whether changes such as rotating reviewers or expanding CODEOWNERS coverage improve the spread.
Related articles
Using the Cross Team toggle in the Review Response Time Report
Review Response Time (Average)
How Span attributes metrics to teams
Need help?
Contact your Span account team or reach out to support@span.app.