PRs Reviewed / Week Report

Last updated: October 27, 2026

PR reviews / week shows how many reviews a typical active contributor submits in a week. It tells you whether review capacity keeps up with the pull requests (PRs) your team writes, and how review work is shared.

Why it matters

  • Review load: shows who carries the review work and whether it's concentrated on a few people.

  • Bottlenecks: low review rates next to high PR cycle times point to review capacity problems.

  • Contribution beyond authoring: recognizes people who help the team through review and mentoring.

How it works

PR reviews / week = review submissions ÷ active contributor-days × 7

  1. Span collects reviews from your version control system. GitHub sends native reviews. On GitLab and Bitbucket Cloud, approvals, change requests, and the first comment per author per PR per hour count as reviews. On Azure DevOps, approve, "waiting for author", and reject votes count.

  2. Span keeps reviews by people marked Contributor and drops self-reviews, reviews in ignored repositories and branches, and reviews by ignored Git usernames.

  3. Numerator: review submissions whose submission time falls in the period. Each submission counts, in any state: approved, changes requested, commented, or dismissed. Two reviews on one PR count as two.

  4. Denominator: active contributor-days: days a person marked Contributor wasn't out of office (OOO) and had code activity (a commit, merged PR, PR review, or PR comment) that day or in the 30 days before it. Weekends count.

  5. Span divides and multiplies by 7. The value shows to one decimal place.

Where to find it: Insights > Productivity > Quality > Code review, team and person Code review tabs, and custom dashboards, with percentile ranks. Catalog > PR Reviews lists each review.

Setup

  1. Connect your version control system.

  2. Mark people who don't write or review code as Non-contributor in Settings > People management.

  3. Connect an OOO source (calendar or HRIS) so time off leaves the denominator.

  4. Add bot accounts to Settings > Metrics > Ignore Git Usernames if needed.

Things to know

  • Worked example. A team of five has 70 active days over two weeks and submits 84 reviews. PR reviews / week = 84 ÷ 70 × 7 = 8.4.

  • Reviews on OOO days still count. OOO days leave the denominator, but a review submitted on an OOO day stays in the numerator.

  • GitHub inline comments count as reviews. GitHub records a standalone inline comment as a review with the "commented" state, so each one adds a review.

  • Reviews on unmerged PRs count, whatever happens to the PR later.

  • Reviewers stay active. A person who only reviews counts in the denominator for 30 days after that activity.

  • Bots: a review counts only if the reviewer maps to a person or a configured dev agent. Report pages show people only by default.

  • Submissions versus distinct PRs: three passes on one PR add three here. Use Unique PRs reviewed / week for distinct PRs. A big gap between the two means many rounds on the same PRs.

  • Team values pool the totals. Span divides the team's total reviews by its total active days. It doesn't average each person's rate.

  • Rough reading guide: more than 10 a week is very high; 6–10 strong; 3–6 solid; 1–3 light; under 1 minimal. Healthy ranges depend on team size, PR frequency, and role.

Related articles

Unique PRs Reviewed / Week

Comments Authored / Week

Review Response Time (Average)

How to read Span's "/ week" metrics

Need help?

Contact your Span account team or reach out to support@span.app.