Metric Definition
PR review latency
Track from
Code review cycle time
Code review cycle time is the elapsed time from when a pull request is ready for review to when it is approved and ready to merge. It captures the wait that sits between writing code and shipping it. Long cycle times slow delivery, stall context, and frustrate the engineers waiting on feedback.
7 min read
What is code review cycle time?
Code review cycle time is the elapsed time from when a pull request is ready for review to when it is approved and ready to merge. If a pull request is opened for review at 9am on Monday and approved at 3pm on Tuesday, the cycle time is 30 elapsed hours, or 14 working hours if the team works an eight-hour day from 9am to 5pm.
The metric isolates one stage of the delivery pipeline. It is not the time spent writing the code, and it is not the time spent in continuous integration or deployment. It is the wait between asking for review and getting a decision. That wait is often the single largest source of delay in a delivery pipeline, because it depends on another person becoming available rather than on the work itself.
Definition note
Measure cycle time from the moment a pull request is marked ready for review, not from when the branch was first created. Drafts and work in progress should not count. Including draft time conflates how long the author took to write the code with how long reviewers took to respond.
How to calculate code review cycle time
Code review cycle time is the difference between two timestamps. You record when the pull request became ready for review and when it received its final required approval, then subtract one from the other.
Most teams report the median rather than the mean. A handful of pull requests that sit open for weeks will drag the average upward and hide the typical experience. The median tells you what a normal review feels like for the team. Report both the median and the 90th percentile so you can see the typical case and the long tail at the same time.
- 1
Capture the review request timestamp
Record the moment the pull request leaves draft state and is marked ready for review.
- 2
Capture the approval timestamp
Record the moment the final required reviewer approves the pull request.
- 3
Subtract to get the per-PR cycle time
Approval timestamp minus review request timestamp gives the cycle time for that pull request.
- 4
Aggregate across the period
Take the median and the 90th percentile across all pull requests merged in the week or sprint.
Code review cycle time in a metric tree
A single cycle time number tells you the wait is too long, but not why. A metric tree decomposes the wait into the stages that make it up, so you can see which one is dragging. Most cycle time is not active reviewing. It is dead time spent waiting for a reviewer to pick the work up, waiting for the author to respond to comments, and waiting for the next round.
Breaking the metric into time to first review, review iteration count, and rework turnaround turns a vague complaint into a specific target. If first review latency is twelve hours and active review takes twenty minutes, the problem is reviewer availability, not review thoroughness.
Metric tree insight
When you decompose cycle time into stages, the dominant stage is almost always time to first review. That stage is owned by the team rota and the reviewer load, not by the author. Pointing improvement effort at the right stage is the whole point of the tree.
Code review cycle time benchmarks
Cycle time varies with team size, time zone spread, and how the team batches work. The ranges below give a rough sense of where teams sit. Elite teams keep the typical pull request moving in hours rather than days, largely by keeping pull requests small and reviewers responsive. Treat these as directional rather than absolute, because a team shipping infrastructure changes will reasonably review more slowly than one shipping copy tweaks.
| Performance tier | Median cycle time | Time to first review | What it signals |
|---|---|---|---|
| Elite | Under 4 hours | Under 1 hour | Small PRs, reviewers respond same session |
| Strong | 4 to 12 hours | 1 to 4 hours | Reviews land within the working day |
| Average | 1 to 2 days | 4 to 24 hours | Reviews often slip to the next day |
| Needs attention | Over 2 days | Over 1 day | Work stalls, context decays, authors block |
How to improve code review cycle time
The fastest lever is almost always pull request size. Small pull requests get reviewed faster because they are easier to reason about and easier to fit into a gap between other tasks. The second lever is reviewer responsiveness, which is a team agreement rather than an individual habit.
Shrink pull requests
Aim for changes under 200 lines. Smaller diffs get a faster first review and fewer rounds.
Set a first-review SLA
Agree a target such as a first response within two hours, and make the rota visible.
Spread reviewer load
Avoid funnelling every review to one senior engineer. A single bottleneck reviewer caps the whole team.
Cut rework rounds
Front-load context in the pull request description so reviewers approve in one pass, not three.
Common mistakes when tracking code review cycle time
- 1
Counting draft time
Starting the clock at branch creation blends authoring time with review wait and hides the real bottleneck.
- 2
Reporting the mean
A few stalled pull requests inflate the average. Use the median and the 90th percentile instead.
- 3
Ignoring time zones
A distributed team will show longer cycle times by design. Segment by team or region before judging.
- 4
Optimising the wait by rushing review
Cutting cycle time by approving without reading trades a speed metric for a quality problem.
Related metrics
Cycle time
Process speed
Operations Metrics
Metric Definition
Cycle Time = Process End Time − Process Start Time
Cycle time measures the total elapsed time from the start to the end of a process. It is a fundamental operations metric used in manufacturing, software development, service delivery, and any context where the speed of a process directly affects throughput, cost, and customer satisfaction.
Deployment frequency
DORA metric
Operations Metrics
Metric Definition
Deployment Frequency = Number of Production Deployments / Time Period
Deployment frequency measures how often an organisation successfully releases code to production. It is one of the four DORA (DevOps Research and Assessment) metrics that predict software delivery performance and organisational outcomes. Teams that deploy more frequently deliver value to users faster, reduce the risk of each individual release, and create tighter feedback loops between development and production.
Sprint velocity
Agile planning metric
Operations MetricsMetric Definition
Sprint Velocity = Sum of Story Points Completed in a Sprint
Sprint velocity measures the amount of work a team completes during a sprint, typically expressed in story points, ideal days, or another unit of estimation. It is a planning tool that helps agile teams forecast how much work they can commit to in future sprints based on their historical completion rate. Velocity is one of the most widely used and most frequently misunderstood metrics in agile software development.
Metric decomposition
Metric Definition
Decomposing code review cycle time into stages such as wait, first response and rework shows exactly where review latency builds up and which part to act on.
Metric trees for engineering teams
Metric Definition
This guide shows how engineering teams place review latency metrics like code review cycle time within a wider delivery tree alongside throughput and quality.
Build code review cycle time as a metric tree with owners on every branch
KPI Tree decomposes cycle time into time to first review, active review, and rework turnaround, then assigns an accountable owner to each branch. When the wait climbs, the owner of that stage hears about it, so the fix lands where the delay actually lives.
