PRs Reviewed Metric

Definition

PRs Reviewed measures the number of pull requests that received at least one recorded review event within the selected time range.

A pull request is counted as “reviewed” if at least one qualifying review action occurred on it during the time range.

Qualifying review actions include:

• Review submission (approve / request changes)
• Review comments associated with a formal review
• Explicit review events recorded by the Git provider

General discussion comments that are not tied to a review event may not qualify, depending on integration capabilities.

How the Metric Is Calculated

PRs Reviewed is calculated as:

Number of unique pull requests that had ≥1 review event during the selected time range

In the dashboard, this value is normalized as: PRs reviewed per day

The headline value represents:

Total reviewed PRs ÷ Number of days in the selected time range

This normalization ensures comparability across different time ranges.

Counting Logic

• Each PR is counted once per time range, regardless of the number of review events.
• Multiple review events on the same PR do not increase the count.
• Only PRs with at least one qualifying review event are included.
• PR state (open, merged, closed) does not affect inclusion — review activity is the determining factor.

How the Metric Is Displayed in the Dashboard

The metric card displays two types of values:

1. Headline Value (e.g., 31.21 PRs per day)

The large number shown at the top represents the average number of PRs reviewed per day across the selected time range.

This is a daily average — not a total count.

2. Time-Based Values in the Chart

The line chart shows how many PRs were reviewed in each time bucket (for example, per day).

Each point represents:

The number of unique PRs that received at least one review event during that specific time bucket

The headline value is calculated across the entire selected time range, not by averaging the daily bucket values.

What This Metric Reflects

PRs Reviewed reflects review throughput — how many pull requests receive review attention.

It does not measure:

• Review quality (see: Review Depth)
• Time to review (see: Review Time)
• Merge rate (see: Merge Frequency)
• PR volume (see: PRs Opened)

How to Interpret PRs Reviewed

Higher values may indicate:

• Strong review participation
• Healthy collaboration
• High review bandwidth

Lower values may indicate:

• Review bottlenecks
• Reviewer overload
• Inactive review cycles

Interpretation should consider:

• PRs Opened
• Merge Frequency
• Review Depth
• Team size

PRs Reviewed should not exceed PRs Opened over extended periods unless backlog review is occurring.

Data Sources

Derived from:

• Git provider review events
• Review submissions (approve / request changes)
• Review metadata APIs

Tunable Configurations

May be influenced by:

• Repository inclusion/exclusion filters
• Branch filtering rules
• Integration configuration
• Service or team filters

Limitations

• Counts review occurrence, not review quality.
• Does not distinguish between superficial and thorough reviews.
• Provider-specific review event definitions may vary.
• Review comments outside formal review flows may not always be captured.
• Small datasets may show volatility.

PRs Reviewed measures review coverage — not review depth or effectiveness.

Stakeholder Use Cases

Engineering Managers

• Monitor review coverage across teams.
• Identify review bottlenecks.

Team Leads

• Ensure PRs are receiving timely attention.
• Balance reviewer workload.

DevOps / Platform Leads

• Assess review flow health before merges.

Product / Delivery Leaders

• Validate that work is progressing through review stages.