PR Cycle Time: How to Measure It and Actually Reduce It

What Is PR Cycle Time?

PR cycle time is the duration from the moment a pull request is opened to the moment it is merged. But measuring the total alone tells you almost nothing. The value comes from decomposing it into stages:

• Time to first review — the void between "opened" and "anyone cares". Often the largest single component.
• Review turnaround — from first review to last approval, including every bounce-back to the author.
• Time to merge — from final approval to the actual merge. Yes, even this gap exists.

Median PR cycle time hides the problem. A team with a 12-hour median and a 4-day P90 does not have a median problem — it has a queueing problem for a minority of PRs that quietly blocks releases.

Why the Median Lies

Most teams look at the average or median PR lifetime and conclude things are fine. Then a critical hotfix takes 3 days to merge because it opened on a Friday afternoon and sat in the queue with forty other PRs. Use the P90, not the median: the 90th percentile captures the tail where your actual delivery pain lives. A flat median with an exploding P90 means the problem is targeted, not systemic — find which PRs live in that tail and ask what they have in common.

The Four Fixes That Actually Move the Number

1. First review within one working hour

The norm is not "finish a full review in one hour" — it is "respond within one hour". A first comment — even "on it, review done by 3pm" — kills the uncertainty that makes authors idle or switch context. The single cheapest fix for PR cycle time is a rotation or a norm that guarantees somebody is watching the review queue.

2. Blocking vs non-blocking feedback

Typo comments, style nitpicks, and "nice to have" suggestions should not cost a second review round. Adopt a convention: blocking comments must be resolved before merge; non-blocking ones are optional follow-ups. Teams that make this distinction typically cut one full review round-trip per PR.

3. A 200–400 line PR ceiling

Review time does not scale linearly with size — research on review quality suggests effectiveness degrades roughly 4x as PR size doubles. Above ~400 lines, reviewers skim, catch fewer real defects, and defer comments that never get addressed. A ceiling forces smaller, faster-to-review changes.

4. Watch the queue, not the workers

Two reviewers at 80% utilization will set the pace for the entire team, because queueing delay explodes as utilization approaches 100%. If you track review load per person, you will see that PR cycle time is a workload-distribution problem before it is a "developers are slow" problem.

How to Collect It Without Nagging Developers

PR cycle time is fully derivable from GitHub events — opened, first review, approval, merge — which means it can be collected passively. No timers, no standup questions, no developer overhead. Every metric worth tracking has this property: it measures the system, not the person.

DevLyTicks computes PR cycle time, time to first review and P90/P50 breakdowns automatically from your repositories — visible in a live dashboard at devlyticks.com.

Bottom Line

PR cycle time is where delivery speed is won or lost for most teams — and it responds to organizational fixes, not heroics: fast first response, blocking/non-blocking discipline, a size ceiling, and balanced review load. Measure it per stage, watch the P90, and fix the queue before you blame the people.