Pull Request Approval Rate

Pull Request Approval Rate measures the percentage of pull requests that are approved and merged without requiring significant changes or rejection. This metric is calculated by dividing the number of approved pull requests by the total number of pull requests submitted over a specific time period, then multiplying by 100 to get a percentage. The pull request approval rate formula provides engineering teams with crucial insights into code quality, developer skill levels, and the effectiveness of their development processes.

A high pull request approval rate typically indicates that developers are writing quality code that meets team standards, following established coding practices, and effectively collaborating with reviewers before submission. Conversely, a low approval rate may signal issues with code quality, unclear requirements, inadequate testing, or misaligned expectations between team members. This metric directly informs decisions about developer training needs, code review process improvements, and resource allocation for quality assurance.

Pull Request Approval Rate is closely related to several other development metrics, including Code Review Cycle Time, Code Review Velocity, and Developer Productivity Score. Together, these metrics provide a comprehensive view of development workflow efficiency and help identify bottlenecks in the code review process. Teams can explore Pull Request Approval Rate using their GitHub data to gain deeper insights into their development patterns and implement targeted improvements through Pull Request Bottleneck Analysis.

The pull request approval rate formula provides a straightforward way to measure how efficiently your development team’s code review process operates.

Formula:
Pull Request Approval Rate = (Approved Pull Requests / Total Pull Requests) × 100

The numerator represents pull requests that were approved and merged on their first review cycle without requiring substantial changes. These are PRs where reviewers gave immediate approval or requested only minor formatting adjustments that didn’t necessitate re-review.

The denominator includes all pull requests submitted during your measurement period, regardless of outcome. This encompasses approved PRs, rejected PRs, and those requiring multiple revision cycles before approval. You’ll typically extract these numbers from your version control system’s API or review dashboard.

Worked Example

Consider a development team’s monthly performance:

• Total pull requests submitted: 150
• Pull requests approved on first review: 105
• Pull requests requiring revisions: 35
• Pull requests rejected: 10

Calculation:
Pull Request Approval Rate = (105 / 150) × 100 = 70%

This indicates that 70% of submitted code met quality standards immediately, while 30% required additional work or was rejected.

Variants

Time-based variants include daily, weekly, monthly, or quarterly measurements. Weekly calculations provide rapid feedback for process improvements, while quarterly metrics better reflect long-term trends and account for project complexity variations.

Scope variants can focus on specific teams, repositories, or feature types. Team-specific rates help identify training needs, while repository-based metrics reveal codebase complexity differences.

Strictness variants define “approval” differently. Some organizations count PRs requiring minor changes as approved, while others only include zero-revision approvals for stricter quality measurement.

Common Mistakes

Including draft or work-in-progress PRs inflates your denominator artificially. Only count PRs submitted for formal review to maintain accuracy.

Mixing approval criteria occurs when different reviewers apply varying standards. Establish clear approval guidelines to ensure consistent measurement across teams and time periods.

Ignoring external factors like onboarding new team members, adopting new technologies, or changing coding standards can temporarily impact rates. Context matters when interpreting trends and setting realistic improvement targets.

It’s natural to want benchmarks for pull request approval rate, but context matters significantly. While benchmarks provide useful guidance for understanding where your team stands, they should inform your thinking rather than serve as rigid targets to chase.

Pull Request Approval Rate Benchmarks

Source: Industry estimates based on development team surveys and GitHub data analysis

Understanding Benchmark Context

These benchmarks help establish whether your pull request approval rate is within expected ranges, but remember that metrics exist in tension with each other. As you optimize one metric, others may shift. A high approval rate might indicate efficient code reviews and strong development practices, but it could also suggest overly lenient review standards or insufficient code quality checks.

Your average pull request approval rate should be evaluated alongside related development metrics to get the complete picture. Consider factors like team size, code complexity, regulatory requirements, and development velocity when interpreting your numbers.

Related Metrics Interaction

Pull request approval rate directly impacts other development metrics. For example, if your approval rate increases from 70% to 90%, you might see code review cycle time decrease as fewer iterations are needed. However, this could coincide with rising bug rates if reviewers become less thorough to maintain high approval rates. Similarly, teams prioritizing rapid feature delivery might accept lower approval rates to maintain development velocity, while regulated industries typically maintain higher approval rates to ensure compliance and code quality standards.

When your pull request approval rate drops, it signals friction in your development workflow that can cascade into longer Code Review Cycle Time and reduced Developer Productivity Score. Here’s how to diagnose what’s causing the bottleneck.

Inconsistent Code Quality Standards
Look for patterns where PRs are rejected for different reasons across reviewers. If similar code changes get approved by one reviewer but rejected by another, your team lacks unified quality standards. This creates confusion and increases rejection rates as developers can’t predict what will pass review.

Oversized Pull Requests
Large PRs with hundreds of lines changed almost always face higher rejection rates. Check your Pull Request Bottleneck Analysis for PRs sitting in review limbo. When reviewers see massive changes, they either rush through (missing issues) or demand extensive revisions, both hurting approval rates.

Insufficient Pre-Review Testing
If PRs consistently fail due to broken tests, missing edge cases, or basic functionality issues, your pre-submission process needs work. Monitor whether rejected PRs correlate with CI/CD failures or basic quality checks that should happen before review.

Review Process Bottlenecks
When Code Review Velocity slows down, context gets lost and reviewers become more conservative, leading to more rejections. Check if your approval rate drops correlate with longer review times or reviewer unavailability.

Skills Gaps or Knowledge Silos
Junior developers or those working in unfamiliar codebases often see lower approval rates. Look for patterns where specific team members consistently face more rejections, indicating they need additional support or mentoring.

Understanding why your pull request approval rate is low helps you target the right improvements to streamline your development process.

Implement pre-commit quality gates
Establish automated checks that catch common issues before code review. Set up linting, formatting, and basic testing in your CI pipeline to prevent trivial rejections. This addresses the root cause of preventable code quality issues. Validate impact by tracking the percentage of PRs that fail initial automated checks versus manual review feedback.

Standardize code review guidelines
Create clear, documented standards for what constitutes approvable code. Include examples of common rejection reasons and acceptable solutions. When teams lack consistent criteria, approval rates suffer from subjective decision-making. Measure success by analyzing rejection reason trends before and after implementing guidelines using cohort analysis to isolate the impact.

Right-size pull requests
Break large PRs into smaller, focused changes that are easier to review and approve. Large PRs correlate with higher rejection rates due to increased complexity and review fatigue. Track PR size metrics alongside approval rates to identify optimal change sizes for your team. Pull Request Bottleneck Analysis can help identify size-related patterns.

Establish reviewer assignment strategy
Match reviewers to PRs based on domain expertise and availability rather than random assignment. Mismatched reviewers often lack context to provide effective feedback, leading to multiple review cycles. Monitor approval rates by reviewer pairing to identify the most effective combinations and optimize assignments accordingly.

Create feedback loops with rejection analysis
Regularly analyze rejection reasons and patterns to address systemic issues. Use your existing data to identify whether rejections cluster around specific developers, components, or time periods. This data-driven approach helps you target improvements where they’ll have the most impact on your overall Developer Productivity Score.

Stop calculating Pull Request Approval Rate in spreadsheets and missing critical insights into your development workflow. Connect your data source and ask Count to calculate, segment, and diagnose your Pull Request Approval Rate in seconds, helping you identify bottlenecks and optimize your code review process.