PR Reports

PR reports focus on the details that reflect how well the team performs regarding the PRs, responses, changes, and comments. 

This helps managers to identify the latencies of the code review process and gives ideas on which parts are not working correctly. The managers can use the reports to reach a better delivery process and solve issues as a result of bottlenecks in the process.

Time to Close/Approve Trend

The trend chart shows how long pull requests take to close (or approve) over time using percentile-based distribution instead of averages. The P50 (median) line represents the typical duration, while the P75 line highlights slower pull requests. This allows you to see both the general behavior of the system and the upper range where delays occur.

The shaded band between P50 and P75 represents the spread between typical and slower pull request completion times. A widening band indicates increasing inconsistency (more variation in completion times), while a narrowing band suggests a more predictable process. If the P50 and P75 lines move very close to each other or overlap, it means most pull requests are being completed within a similar timeframe, indicating a consistent process with low variability.

Threshold lines at 2 days and 5 days help quickly assess performance. If the percentile lines move above these levels, it indicates potential bottlenecks or delays in the delivery process. This chart is best used for identifying trends, stability, and risk areas in the pull request lifecycle, rather than precise measurement.

Time to Resolve

Time to Resolve measures the duration from when a PR is opened to when it is merged (or closed).

This is a general overview of the PR history so that the managers can identify if PRs are closed for a longer than expected period. Also, this enables them to get into the details of the PRs that are open for a long period to help the team resolve the issue.

Time to First Action

This metric shows the time that passes for any viewer to take an action on the PR after it is opened. (e.g., comment or approval).
 

This valuable data reflects how responsive the reviewers are in the PR process. It is logical to expect that the sooner the action is taken the quicker the submitter can get the feedback and progress.

PR Maturity

PR Maturity measures how much a pull request evolves after it is opened for review. It is calculated based on the ratio of follow-up commits to the total number of commits in the PR. Higher maturity levels indicate that the PR was largely complete at the time of submission, while lower maturity levels may suggest that changes continued during the review process. This metric helps identify whether PRs are being opened in a review-ready state or prematurely.

Review Density

Review Density evaluates the level of review feedback relative to the size of code changes. It compares the number of review comments to the total lines modified in the PR. Low density may indicate lightweight or surface-level review, whereas high density can signal complex changes or friction during review. This metric provides visibility into review depth and feedback intensity.

Discussion Intensity

Discussion Intensity reflects how actively a PR was discussed during its lifecycle. It is derived from the number of review comments normalized by the PR’s review time. Higher intensity suggests concentrated feedback and active engagement, while lower intensity indicates smoother or minimal discussion. This metric helps assess collaboration dynamics during code review.

Rework Pressure

Rework Pressure measures the combined impact of reviewer involvement and post-review commits. It considers both the number of reviewers and the number of follow-up commits made after review began. Higher pressure levels may indicate iterative clarification, alignment challenges, or complex changes. This metric helps surface patterns where review cycles introduce significant rework.

Follow-on Commits

The number of code updates after the PR is opened. 

The high number of commits after the PR opened may indicate a problem with the development cycle. Therefore, it would be best to increase the focus on the testing process.

Reviewer Comments

Reviewer comments are provided in terms of count and it shows how many comments are made generically on the open PRs by reviewers.

If the number is high, we suggest you check the reasons why the PRs are getting more comments than expected. It may indicate failure in the coding phase, the contributors may be exploring new patterns or languages or any disagreement on the way of coding.

Reviewers

Reviewers metric shows how many reviewers have been actively involved in the PR process during the specified time period.

Avg. Comments Per Reviewer

This is another metric to understand the number of reviewer comments but in this case, it presents the count for each reviewer.

The metric can indicate how much involvement reviewers have in the PR process. Therefore, the spikes in this report may indicate an issue regarding the coding or review processes.