iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A pull request’s open-to-merge time is elapsed time, not time spent actively reviewing code. It can include waiting for a first human response, review and revision rounds, CI, and a delay after approval. Those stages do not add up the same way for every team, so measure them separately before deciding whether waiting or rework is the main problem.
What counts as pull request review time?
“Review time” often means the entire interval from opening a pull request (PR) to merging it. That interval includes work and waiting by different people and systems; it is not a measure of how long reviewers actively read or discuss the change.
A useful timeline is:
- PR submitted
- Wait for the first human response
- Review comments and discussion
- Author revises the change
- Further review, if needed
- Approval
- Merge
CI and build activity can overlap several stages, so track it as its own interval rather than assuming it is all reviewer time or all author rework. A bot acknowledgment should also be recorded separately from a human response: it may confirm that a PR was received without providing meaningful review.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsIs PR time mostly waiting and rework?
It can be in a particular team, but available studies do not establish that waiting and rework make up most PR time across organizations. A study of 3,347,937 pull requests across 11,230 GitHub projects found that factors associated with latency changed by stage. At submission, relevant factors included description length, code changed, developer experience, reviewer activity, and project workload. For PRs with comments, first-comment latency and comment count mattered; for PRs using CI, build latency and results mattered. These are observational findings, not proof that any one factor causes delay in every team. See Pull Request Latency Explained: An Empirical Overview.
#1 Best Overall
Another study examined 111,094 closed PRs from ten popular GitHub open-source projects and analyzed bot-generated and human-generated first responses separately. That distinction matters operationally: a fast automated acknowledgment does not tell you how long an author waited for a reviewer to engage. See Understanding the Time to First Response In GitHub Pull Requests.
Post-approval waiting can also be substantial in some settings. A study of roughly half a million reviews on Gerrit and Phabricator reported that waiting between acceptance and merge accounted for 29%–63% of total review lifetime in the sampled Phabricator projects. Its median post-acceptance share was 43.00% for Phabricator and 1.00% for Gerrit. The samples differed, so this is not evidence that one platform causes faster merging, nor a universal estimate for PRs. It does make the approval-to-merge interval worth measuring. See Mining Code Review Data to Understand Waiting Times Between Acceptance and Merging: An Empirical Analysis.
How to identify where your PRs lose time
Build a stage-level view from your repository data. For each PR, capture timestamps for submission, first human response, comments, author updates, approval, CI completion, and merge where available. Calculate durations between events instead of relying only on open-to-merge time.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Separate human response from bot acknowledgment. Otherwise, an automated receipt can make first-response performance look better than the author’s experience.
- Track review rounds and author revision intervals. They help distinguish time spent waiting for feedback from time spent making changes.
- Measure CI separately. A slow or repeatedly failing build can hold up progress even when reviewers respond promptly.
- Measure approval-to-merge time. Approval is not the same as a completed change.
- Look at both the median and a tail measure such as P75. The median describes a typical PR; a higher percentile can reveal a smaller group of changes that wait much longer.
Keep the measures consistent: define when each clock starts and stops, and compare similar PR types or project areas where possible. A change in the overall average may reflect a different mix of PRs rather than a change in the workflow itself. Meta has described using P75 Time In Review as an operational measure, but its choice is an example, not a universal standard for every team.
Match the intervention to the delayed stage
Treat each long interval as a hypothesis to investigate, not an automatic diagnosis. The same end-to-end duration can arise from different bottlenecks, and a process change should be evaluated against the stage it is intended to improve.
| Where time accumulates | What to investigate | Possible response |
|---|---|---|
| Before the first human response | Reviewer ownership, workload, routing, and whether requests reach an available reviewer | Make ownership clearer, improve routing, or set expectations for when a reviewer will respond |
| Across multiple review rounds | Change size, clarity of the description, unresolved design questions, and whether comments lead to repeated revisions | Make changes easier to review, explain intent and trade-offs, or discuss design concerns earlier |
| During CI or builds | Build duration, reliability, and whether failures block review or merge | Investigate slow or flaky checks and clarify which checks must pass before merging |
| After approval | Who owns the merge, remaining checks, and friction in the merge path | Clarify merge ownership or reduce avoidable manual steps where safe |
These are practical starting points, not guaranteed fixes. Compare the relevant stage before and after a change, and check that review quality has not suffered.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Improve response speed without creating constant interruptions
Faster feedback can keep work moving, but making every request an interruption can fragment reviewers’ focused work. Google Engineering Practices advises that “One business day is the maximum time it should take to respond to a code review request (i.e., first thing the next morning).” That is Google’s internal guidance, not a universal service-level standard. Its broader principle is to support the speed of the team while protecting careful review.
If a reviewer cannot complete a full review promptly, Google suggests communicating when they expect to review, asking another reviewer to take it, or offering broad initial feedback at a natural break point. When a change is too large to review in one sitting, the guidance is to ask whether it can be split into smaller changes that build on each other. A smaller diff can make review more manageable, but it should preserve a coherent, understandable change rather than simply shift complexity into extra PRs.
Best Value
Authors can reduce avoidable back-and-forth by stating what changed, why it changed, what reviewers should focus on, and whether there are known trade-offs. Reviewers can make next steps clear, distinguish blocking issues from minor suggestions, and communicate explicitly about small unresolved comments when approving. These practices are worth testing against the team’s own round counts and latency, not assuming they will produce the same results everywhere.
What company results do—and do not—show
Meta reported that a change to its reviewer recommendations was associated with a 1.5 percentage-point increase in diffs reviewed within 24 hours. Meta also reported that the accuracy of its top-three reviewer suggestions rose from below 60% to nearly 75%. Those are Meta’s reported system outcomes, not a benchmark or promised result for another organization. Its account also describes tracking P75 Time In Review and using a bot to nudge reviewers about stale diffs. See Meta Engineering’s account of improving code review time.
Google Research reported that authors applied machine-learning-suggested edits to 7.5% of reviewer comments in a deployment at Google. That figure describes adoption of suggested edits; it does not establish a general reduction in review duration or show that AI tools remove the need for human judgment. See Resolving Code Review Comments with Machine Learning.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
