Pull request approval rate

Pull request approval rate is the percentage of opened pull requests that are reviewed, approved, and merged within a given period. If a team opens 100 pull requests in a month and 85 are approved and merged, the approval rate is 85 percent. The remaining 15 were closed without merging, abandoned, or are still open past the window. The metric captures how reliably proposed changes make it through review into the codebase.

Approval rate matters because it sits at the junction of speed and quality in software delivery. A very high rate can mean a smooth, trusting review culture, or it can mean review is a rubber stamp that catches nothing. A low rate can mean rigorous quality control, or it can mean churn: changes opened too early, reworked repeatedly, or blocked by unclear standards. The number alone does not tell you which, so it must always be read with context.

The most useful way to read approval rate is as a flow signal. When it drifts down while the team is unchanged, something in the review pipeline is creating friction: reviewers are overloaded, standards are ambiguous, or work is arriving in chunks too large to approve. Tracked over time and paired with review wait time, it becomes an early warning that the path from written to merged is getting harder.

The base calculation divides approved and merged pull requests by the total opened in the same window, then multiplies by 100. To make the result diagnostic rather than decorative, break the denominator and the outcomes into their component parts so you can see why requests do or do not get merged.

1. 1

   Approved and merged PRs

   Pull requests that received the required approvals and landed on the main branch. This is the numerator and the outcome the rate is built around.

2. 2

   Total PRs opened

   Every pull request opened in the period, regardless of final state. Using opened rather than closed requests keeps the denominator honest and tied to a fixed window.

3. 3

   Closed without merge

   Requests that were rejected, superseded, or abandoned. A rising share here is the clearest signal that review is producing churn rather than throughput.

4. 4

   Review rounds per PR

   How many back-and-forth review cycles a request needs before approval. A high rate achieved only after many rounds hides friction that the headline number does not show.

These inputs separate two very different situations that produce a similar approval rate. A team where most requests merge on the first review round has a fast, trusted pipeline. A team where requests eventually merge but only after four rounds of rework has the same approval rate and a much worse experience. Pairing the rate with review wait time and with cycle time shows whether approvals are happening cleanly or only after a long, costly path.

A metric tree decomposes approval rate into the factors that determine whether a proposed change reaches the main branch. This turns a single percentage into a view of where review is working and where it is creating drag.

The first level splits the rate into change quality, review capacity, and standards clarity. Change quality governs whether requests arrive in a mergeable state. Review capacity governs whether there are enough reviewers with enough time to act on them. Standards clarity governs whether authors and reviewers agree on what good looks like, which is the difference between productive rejection and avoidable churn. Each branch decomposes into levers a specific owner can act on.

The tree makes a falling approval rate diagnosable. It shows whether requests are being rejected for real quality reasons, blocked by reviewer overload, or bounced because expectations were never made explicit. Each of those is a different problem with a different owner.

Approval rate benchmarks depend on how a team works, but most healthy engineering teams land in a recognisable band. The goal is not to maximise the rate, since a perfect 100 percent usually means review is not catching anything. The goal is a high rate achieved with few review rounds.

Read approval rate together with review rounds per request and review wait time. A team at 90 percent approval with most requests merging in one round has a genuinely healthy pipeline. A team at 90 percent that needs three or four rounds per request has hidden friction that the headline figure conceals. The same care applies to sprint velocity: approvals that take many rounds quietly drain the iteration even when the merge eventually lands.

Improving approval rate means reducing avoidable churn, not lowering the bar. The strongest levers make requests easier to review and make expectations explicit before review even starts.

The metric tree approach starts by finding the branch with the most room to improve. If oversized requests dominate, splitting work will move the rate more than adding reviewers. If review wait time is the constraint, rebalancing reviewer load matters most.

KPI Tree lets you model approval rate this way by connecting each branch to the part of the team that owns it. Authors own request size and pre-review checks. Reviewers own turnaround and load balance. The engineering lead owns the standards that define a mergeable change. With RACI ownership on every node and a push to the accountable owner when the rate moves, a dip in approvals becomes a specific signal to a named person rather than a chart nobody acts on.

1. 1

   Chasing 100 percent

   A perfect approval rate usually means review is not filtering anything. The aim is a high rate with substantive review, not approval of everything that is opened.

2. 2

   Reading the rate without review rounds

   Two teams with the same rate can have very different experiences. One merges in a single round, the other after four. Always pair the rate with how much rework approvals require.

3. 3

   Measuring against open PRs instead of opened

   Calculating against everything currently open rather than requests opened in a fixed window makes the rate swing for reasons unrelated to review quality.

4. 4

   Turning the rate into an individual target

   Tying approval rate to individuals pushes reviewers to approve faster and authors to game the metric. It is a process signal, not a personal score.

5. 5

   Ignoring abandoned requests

   Requests that are quietly abandoned still represent wasted effort. Tracking only merged and rejected outcomes hides a real source of churn in the denominator.