Skip to main content

Code Review Stats

The Code Review Stats page shows patterns and blockers in your code review process — review time trends, reviewer workload distribution, PR volume, and response time. Use it to identify where reviews slow down and who may be overloaded.

Written by Aika Apolinario
Updated today

Accessing Code Review Stats

Navigate to More Reports > Code Review Stats from the left sidebar. The subtitle reads: "Patterns and blockers for your code review process."


Filters

The same filter bar as other reports appears at the top:

Filter

Options

Date range

Preset ranges (Last 3 Months, etc.) or custom dates

Team selector

My Teams, All Teams, or specific teams

Apply Filter

Additional filters (repositories, members)

Save Filters

Save your current filter combination

A "Showing all Repositories" badge appears when no repo filter is applied. Click Export in the top-right to download the data.


Charts on the Page

Review Time

What it shows: Time from pull request open to merging a pull request, displayed as a trend line chart over the selected period.

The headline number shows the current value (e.g., 68.91 hours) with a trend arrow indicating whether review time is improving (green down arrow) or worsening (red up arrow) compared to the previous period.

The chart shows gray data points (weekly values) and a blue trend line, just like the Metric Hall charts.


# of Review Assigns by Developer

What it shows: A bar chart ranking team members by how many times they are assigned as a reviewer.

What to look for:

  • A steep drop-off means a few people handle most review assignments — consider spreading the load

  • Members with zero or very few assignments may not be part of the review rotation


# of Reviews by Developer

What it shows: A bar chart ranking team members by how many times they have approved or requested changes on pull requests.

This differs from "Review Assigns" — a developer can be assigned as reviewer but never actually complete the review. Comparing the two charts reveals who is assigned reviews but not completing them.


# of Pull Requests Opened

What it shows: The number of open pull requests over time, displayed as a trend line chart.

What to look for:

  • A rising trend means PRs are being opened faster than they're being merged — the review queue is growing

  • A stable or declining trend is healthy — the team is keeping up with incoming PRs


Time to Respond beta

What it shows: Time between each comment or commit inside a pull request made by different members. Displayed as a trend line chart.

This measures the back-and-forth responsiveness during a review — not just the first response, but every subsequent interaction. High values mean reviewers and authors are slow to respond to each other during the review cycle.


Reading the Charts

All time-series charts on this page follow the same pattern:

  • Gray dots/line — actual weekly data points

  • Blue trend line — smoothed trend direction

  • Hover — shows exact value and date for any data point

Bar charts rank individual developers and show counts. Hover over any bar to see the exact number.


Improving Code Review Speed

Pattern you see

Suggested action

Review Time trending up

Check PR size — large PRs take longer. Set a team guideline (e.g., < 400 lines).

Review load concentrated on 2-3 people

Rotate reviewers using CODEOWNERS or round-robin assignment.

PRs Opened trending up

The team is producing PRs faster than reviewing them. Dedicate time blocks to review.

Time to Respond is high

Set team norms for response time. Use Slack/Teams notifications for review activity.

Big gap between Assigns and Reviews

Some reviewers are assigned but not completing reviews. Follow up or reassign.


FAQ

Q: Are bot PRs included in Code Review Stats? A: No. PRs created by recognized bots (Dependabot, Renovate, GitHub Actions, etc.) are excluded automatically.

Q: What does the "beta" tag on Time to Respond mean? A: Time to Respond is a newer metric still being refined. The calculation and display may change in future updates.

Q: How is Review Time calculated for PRs with multiple reviewers? A: Review Time is measured from PR opened to PR merged, regardless of how many reviewers participate.

Q: Does the headline Review Time number use the 85th percentile? A: Yes. The headline value and trend are based on the 85th percentile, consistent with other time-based metrics in Haystack.

Q: Who can access Code Review Stats? A: Both Admin and Member roles. The data shown depends on the team filter selected.

Did this answer your question?