Tracking time spent on code reviews means measuring the minutes between a reviewer opening a pull request and submitting their verdict. You can capture this from PR event timestamps, activity signals, or timers. The point is to make hidden review work visible for capacity planning and billing.
Most senior engineers spend four to eight hours a week reviewing other people’s code. That effort rarely appears on a timesheet, a sprint burndown, or a client invoice. The work itself is real — defects prevented, architecture questioned, juniors mentored. But because it sits outside the “I wrote this code” column, it gets logged as overhead or forgotten entirely. This guide covers why review time disappears, healthy benchmarks, five ways to measure it, and how to bill reviews the same way you bill development.
Why is code review time invisible on most teams?
Review work leaves thin traces. A developer opens a PR in a browser tab, reads 400 lines, leaves seven comments, and closes the tab. No ticket moved. No commit landed. Nothing in the sprint board shifted. The reviewer’s two hours of focused thinking quietly disappears from every dashboard that tracks engineering output.
Research published in an Empirical Software Engineering study on code review speed found that review latency directly affects team delivery speed. Industry surveys consistently put review effort between 15% and 25% of a developer’s working time. For agencies billing by the hour, that share is pure revenue leakage when it is never logged.
The three costs of leaving review time unmeasured
Capacity planning breaks. Sprint commitments are sized against development time only. A team that actually spends a fifth of its week reviewing ends up over-committed every sprint and cannot explain why deadlines slip.
Senior engineers quietly burn out. Review load concentrates on the few people whose names everyone tags. Without data, nobody sees that one reviewer is approving 60% of team PRs until that person is already looking for another job.
Agencies under-bill. A client paying for “40 hours of development” is also receiving eight hours of senior review effort. If that time is never captured, it is given away free — a direct hit to project margin.
Measuring review time is not about policing reviewers. It is about surfacing work that already exists so it can be planned, distributed, and paid for.
How long should a code review take?
The benchmark most teams work from comes from the SmartBear and Cisco code review study. That study analysed 2,500 reviews across 3.2 million lines of code at a major networking vendor. Two numbers matter: size and duration.
On size, reviews of fewer than 200-400 lines found meaningfully more defects than larger reviews. Reviewers moving slower than 400 lines per hour spotted more problems. Above 450 lines per hour, defect density dropped in 87% of cases.
On duration, total review time should stay under 60 minutes and never exceed 90. Defect detection rates fall off a cliff after that window because cognitive fatigue sets in.
What do real review turnaround times look like?
A 2018 Modern Code Review study at Google found a median review latency of under four hours across roughly nine million reviews. By comparison, Rigby and Bird’s earlier research measured median time-to-approval of 14.7 to 19.8 hours at other large technology firms.
That range — four hours at a well-tuned organisation, nearly a full day elsewhere — is where most teams should benchmark themselves. The gap between an active review taking 30 minutes and turnaround taking 20 hours is mostly waiting, not working. Measuring both separately is the single biggest move most teams can make.
The hidden cost of review interruptions
Every review request is an interruption. A 2008 University of California study on workplace interruptions found it takes 23 minutes on average to refocus after being pulled off a task. Two review requests in an afternoon can cost an engineer close to an hour of recovery time on top of the reviews themselves. Any benchmark that ignores context switching under-counts the true cost of review work.
What methods can you use to track code review time?
Five methods are used in practice. Each captures a different slice of the truth, and most mature teams combine two or three.
Method 1: PR event timestamps for turnaround time
Every git provider emits events with timestamps: review_requested, review_submitted, approved, changes_requested. Pulling these from the REST or GraphQL API gives you review turnaround — wall-clock time from request to verdict — with zero developer effort. It is the easiest starting point and covers the latency question almost entirely.
What it misses is active review time. A PR requested at 09:00 and approved at 17:00 could represent 20 minutes of reading and seven hours of waiting. Turnaround is a delivery signal, not an effort signal.
Method 2: Comment frequency and thread depth as a proxy
A PR with 24 comments across six threads represents more review effort than one with a single “LGTM”. Comment counts, thread depth, and the presence of requested changes all correlate with the work a reviewer actually did. This is a cheap proxy, available from the same API data as turnaround time.
The proxy breaks for silent reviews — a senior engineer who reads carefully and approves without commenting. It is best used alongside a direct measure of review time rather than as the sole signal.
Method 3: Activity-based tracking from editor and browser events
Activity-based trackers watch what a developer is actually doing. They see which PR diff is open in the browser, which file is in focus in the editor, and group those events into review sessions. A reviewer with a PR page active for 35 minutes produces a 35-minute review block against the matching project.
The accuracy is much closer to ground truth than proxies can get. The trade-off is the integration cost: OAuth connections to the git provider plus an editor extension or browser listener. Teams that already map git commits to billable time typically extend the same pipeline with review event capture.
Method 4: Dedicated review timers
The classic manual option: a button the reviewer presses to start a timer when opening the PR and again when submitting. Simple, cheap, and accurate when used. The problem is compliance — reviewers forget, especially on quick reviews, and forgotten timers skew the data downward.
Dedicated timers work best for teams that want explicit ritual around reviews. They are also useful for enforcing the 60-minute limit, rather than as a primary capture method.
Method 5: Automated correlation across the full workflow
The highest-accuracy approach combines PR events, review comments, activity signals, and calendar blocks into a single timeline per developer. A review session appears as “25 minutes on PR #384, triggered by a review request at 14:10, ending at 14:35 on approval”. The underlying events stay visible for audit.
This is the same principle behind setting up time tracking with GitHub — observe the events, do not ask the developer to log. Extended to reviews, it produces a draft review-hours number on Friday afternoon that the reviewer confirms rather than reconstructs.
Choosing a method by team size
| Team size | Recommended method | Why |
|---|---|---|
| 1-5 developers | PR event timestamps + comment counts | Cheap, no integration cost, covers the basics |
| 5-15 developers | PR events plus activity-based tracking | Turnaround alone misses active effort |
| 15+ developers | Correlated automation across events and activity | Manual timers and proxies break at volume |
| Agencies billing by the hour | Correlated automation with repo-to-client mapping | Audit trail matters for client review |
How do you bill clients for code review time?
Review time is client work. An hour spent reviewing a PR for Client A is as attributable to Client A’s project as an hour writing code. Treating it as overhead is a business decision most agencies would reverse if they saw the numbers.
What works when framing review time to clients
Attribute review time to the project the PR belongs to. The repo-to-client mapping you already use for commits covers reviews too. A review on a PR in the acme-checkout repository bills to Acme, the same as the code it reviews.
Make review time an explicit line item in the SOW. Clients who see “Development — 32 hours, Code review — 8 hours” understand the split. They rarely push back on it. Clients who see only “Development — 40 hours” sometimes do, because the total looks inflated.
Charge the same rate as for development. The expertise is the same. The senior engineer catching a race condition in review is applying the same skill they would apply writing the fix. A discounted review rate signals that the work is secondary, which undermines the case for billing it at all.
Frame review as defect prevention. Clients pay for quality, not for “watching someone else code”. A review that catches a bug before production saves the cost of a post-release hotfix plus the reputational damage with end users. That is the value on the invoice.
What about internal reviews on internal projects?
For teams where the client is the business itself, the same logic applies. The output is capacity data rather than an invoice line. If the team has 400 working hours a week but 80 go to reviews, sprint commitments should be sized against 320, not 400.
How do you make review time visible to stakeholders?
Measurement alone changes nothing. Review time data has to land in the places where decisions get made.
Five moves that turn review data into action
- Add review time to sprint capacity calculations. Treat it the same way you treat meetings — real work that reduces available development capacity. Teams that stop planning against 100% development time stop missing sprint commitments.
- Distribute review load from data, not habit. If one reviewer is handling 60% of PRs, rotate assignments or adjust the team’s reviewer pool. Developer productivity without surveillance depends on this kind of data-driven rebalancing rather than anecdotal complaints.
- Set team SLAs for review turnaround. “First review within four working hours” is a common target and one that PR event timestamps make trivially measurable. SLA breaches become visible as data rather than grumbling.
- Publish review time in client reports and retrospectives. A monthly dashboard showing review-to-development ratio, average turnaround, and top reviewers keeps the work visible to everyone who needs to see it.
- Use review time in retrospectives to spot PR outliers. A PR that consumed six hours of review across three reviewers is telling you something — either it was too large, or the domain is unfamiliar, or the description was poor. Fixing the upstream cause prevents the next six-hour review.
What a healthy team looks like on the data
Healthy review data tends to share four properties:
- Median turnaround under eight hours
- Active review time under 90 minutes per PR
- Review-to-development ratio between 15% and 25%
- No single reviewer above roughly 2x the team average
Teams outside those bands are not necessarily broken, but they are usually running a hidden risk. Slow turnaround slows delivery. Long reviews miss defects. Imbalanced load creates burnout. High ratios suggest PRs that are too large. Each signal is visible only when the data is captured.
Key Takeaway
Code review is real engineering work. PR event timestamps give you turnaround for free, activity-based tracking adds active effort, and billing reviews at the same rate as development recovers a fifth of typical project hours.
Frequently Asked Questions
Should code review time be billed to the client?
Yes. Code review is a quality assurance activity tied directly to the project the PR belongs to. Most professional services agreements treat review effort as billable. Framing the line item as defect prevention helps clients see the value.
How do I reduce the time my team spends on code reviews?
Keep PRs under 400 lines and write clear descriptions with screenshots or context. Run automated linters so style issues never reach the reviewer. Use a structured review checklist to cut back-and-forth. Reviews under 60 minutes find more defects, so smaller PRs improve speed and quality at once.
Can I track code review time without installing browser extensions?
Yes. PR event timestamps from your git provider’s API give turnaround time without any browser extension. Activity-based trackers that use OAuth integrations pull the same events from the server side, so there is nothing to install on a reviewer’s machine.
What is a healthy ratio of review time to development time?
Most teams see code review consuming 15% to 25% of total engineering time. Ratios above 30% usually point to PRs that are too large or to review load concentrating on too few people. Ratios below 10% often mean reviews are rushed or rubber-stamped, which shows up later as defects in production.
How long should a single code review take?
Aim for under 60 minutes of active review time and never exceed 90 minutes. Defect detection drops sharply after the 60-minute mark because of cognitive fatigue. If a PR cannot be reviewed in 60 minutes, split it into smaller PRs rather than pushing through a long single review.
Does measuring code review time feel like surveillance to developers?
Not when the data flows to the developer first. A fair system shows each reviewer their own review-time data and lets them correct auto-generated entries. The numbers should feed capacity planning and billing, not individual performance scoring. The test is simple — if the reviewer sees the data first, it is not surveillance.
What is the difference between review turnaround and active review time?
Review turnaround is wall-clock time from “review requested” to “review submitted” — the delivery signal. Active review time is the minutes a reviewer was actually reading the diff and writing comments — the effort signal. Measuring both separately is essential because a PR can have short active time but long turnaround if it sat in a queue.
Ready to make review work visible?
Connect your git provider to Keito and capture review time alongside commits, meetings, and other developer activity. Review hours appear on Friday’s draft timesheet without a timer in sight.