What Is PR Cycle Time? How to Measure and Reduce It

What Is PR Cycle Time and Why Should You Measure It?

PR cycle time — short for pull request cycle time — is the total elapsed time from a developer's first commit on a branch to the moment that pull request is merged into the main codebase. It is one of the most reliable leading indicators of engineering team velocity available, and it requires no surveys, no meetings, and no manual data entry to collect.

When cycle time is short, code moves quickly from development into production. Teams ship more frequently, integration conflicts are smaller, and feedback loops between developers and reviewers are tight. When cycle time is long, the opposite is true: work sits in limbo, merge conflicts accumulate, and the gap between what was built and what was reviewed grows wider with every passing day.

Why it matters: LinearB's analysis of 8.1 million pull requests found that teams in the top quartile for cycle time ship code roughly 3x more frequently than median teams — and experience significantly lower rates of production incidents. Speed and quality are not in opposition when cycle time is managed deliberately.

It is also worth clarifying the relationship between cycle time and lead time, since the two terms are often used interchangeably but refer to different scopes. Lead time measures the full span from when a feature is requested or a ticket is created to when it is deployed to production. Cycle time is a subset of lead time: it covers only the engineering workflow — from first commit to merge. Lead time is a business-level metric; cycle time is a developer-workflow metric. Both matter, and they serve different audiences.

The Four Phases of PR Cycle Time

Treating cycle time as a single number obscures where the time is actually going. Every PR passes through four distinct phases, each with its own causes, benchmarks, and improvement strategies. Understanding which phase is your bottleneck is the first step toward reducing your total cycle time.

Coding Time — First Commit to PR Opened

Coding time captures how long a developer works on a change before opening a pull request for review. This phase is driven primarily by two factors: the size and complexity of the work, and the clarity of the requirements going into it.

Long coding time is often a sign that PRs are too large. A developer building an entire feature end-to-end before opening a PR will accumulate days of coding time. That same feature broken into three focused PRs — each reviewed and merged before the next begins — produces dramatically shorter individual coding times and far fewer integration headaches. Unclear requirements also inflate coding time: developers who must discover requirements through implementation spend significantly more time in this phase than those working from well-defined specifications.

Elite benchmark: Under 6 hours. High-performing teams keep coding time short by enforcing PR size discipline — typically under 400 lines of changed code — and by ensuring requirements are clear before development begins.

Pickup Time — PR Opened to First Review

Pickup time measures how long a pull request sits after being opened before a reviewer leaves the first comment or approval. This phase is the most actionable of the four: it is entirely a function of team responsiveness, not technical complexity.

Pickup time is frequently the single largest bottleneck in the cycle time breakdown. A PR that takes 2 hours to write can sit for 2 days before anyone looks at it. That 2-day wait creates real costs: the author context-switches to other work, the reviewer must re-learn the change when they finally look at it, and any blocking downstream work is delayed by the same amount.

Teams that set explicit pickup time SLAs — for example, a working agreement that any open PR will receive a first review within 2 hours during business hours — see the most immediate improvements in total cycle time. The commitment does not require more reviewers; it requires a different allocation of existing review capacity.

Elite benchmark: Under 1 hour. Achieving this requires dedicated review time blocks, clear reviewer assignment, and tooling that surfaces waiting PRs automatically.

Gitrecap's cycle time phase breakdown, showing where time is spent across each stage of the PR lifecycle.

Review Time — First Review to Approval

Review time covers the back-and-forth between author and reviewer after the first review comment is posted. This phase includes revision cycles: the author addresses feedback, pushes changes, and the reviewer reassesses. A single-round review where the PR is approved on the first pass will produce a short review time. A PR that goes through four rounds of revisions will produce a long one.

Review time correlates strongly with PR size. LinearB's research across 8.1 million pull requests found that PRs exceeding 400 lines of changed code take approximately 3x longer to move from first review to approval compared to smaller PRs. Large PRs are harder to review thoroughly, more likely to generate extensive discussion, and more likely to require multiple revision cycles before all feedback is resolved.

The quality of the PR description also affects review time. A clear explanation of what changed and why — along with testing notes and any relevant context — reduces the number of clarification questions reviewers must ask, compressing the review phase significantly.

Elite benchmark: Under 4 hours. Teams achieve this by keeping PRs small, writing descriptive PR summaries, and using PR templates that standardize the information provided to reviewers.

Merge Time — Approval to Merge

Merge time is the interval between the final approval being granted and the PR actually being merged. In a fully automated pipeline, this should approach zero: once approved, the PR merges immediately or as soon as required CI checks pass.

When merge time is high, it typically indicates one of several problems: CI pipelines that take too long, required status checks that are unreliable, manual merge gates that have not been automated, or unclear ownership of who is responsible for merging approved PRs. Each of these is a process problem, not a code quality problem, and each has a straightforward resolution.

Elite benchmark: Under 1 hour. Teams that use auto-merge tooling — which merges a PR automatically once all required checks pass and approvals are in place — achieve merge times in the single-digit minutes.

How to Calculate Pull Request Cycle Time

The formula for total PR cycle time is straightforward:

Total Cycle Time = Coding Time + Pickup Time + Review Time + Merge Time

Each phase is calculated from timestamps already present in your GitHub data:

• Coding time: Timestamp of the first commit on the branch to the timestamp the PR was opened
• Pickup time: Timestamp the PR was opened to the timestamp of the first review comment or review submission
• Review time: Timestamp of the first review to the timestamp of the final approval
• Merge time: Timestamp of the final approval to the timestamp the PR was merged

Calculating this manually for a handful of PRs is feasible, but doing it consistently across an entire team and multiple repositories is not. Every data point requires pulling commit timestamps, PR event logs, and review submission records from the GitHub API and joining them correctly. Edge cases — force pushes, multiple reviewers, PRs opened as drafts before conversion — add further complexity.

Gitrecap's Cycle Time dashboard handles all of this automatically. Connect your repositories and every PR is classified by phase with no manual calculation required. Trends are tracked over time, outliers are surfaced, and the data is broken down by author, reviewer, and repository.

Gitrecap automatically tracks all four cycle time phases across every PR in your connected repositories.

PR Cycle Time Benchmarks from 8.1 Million Pull Requests

The most comprehensive public dataset on PR cycle time comes from LinearB, which analyzed over 8.1 million pull requests to establish performance benchmarks across four tiers. These benchmarks are widely cited in the industry and align closely with the DORA research on elite, high, medium, and low-performing engineering organizations.

For a full breakdown of benchmarks across all four cycle time phases, see our dedicated guide on cycle time benchmarks.

Source: LinearB, "Engineering Benchmarks Report" (8.1M PR dataset). These benchmarks represent medians within each performance tier, not theoretical maximums. Most teams fall in the medium range when they first start measuring — and that is a normal starting point.

How to Reduce PR Cycle Time — 7 Proven Strategies

Reducing cycle time is not a single intervention — it is a collection of practices that compound over time. The strategies below are ordered roughly by expected impact for a team starting from a medium or low baseline.

1. Keep PRs Small (Under 400 Lines of Code)

This is the highest-leverage change most teams can make. LinearB's data shows that PRs exceeding 400 lines of changed code take approximately 3x longer to move through review compared to PRs under that threshold. The relationship is not linear — there is a sharp inflection point around 400 lines where review thoroughness drops and cycle time spikes.

Keeping PRs small requires discipline at the planning level: breaking features into independently reviewable slices before development begins. This is a skill that improves with practice and team agreement on what "done" means for a reviewable unit of work.

2. Set a Pickup Time SLA

Teams that establish a formal working agreement around pickup time — for example, "any open PR will receive a first review within 2 hours during business hours" — see an average 40% reduction in total cycle time, according to LinearB's research. This single change often has more impact than any technical optimization.

The SLA does not require reviewers to work faster. It requires that reviewing be treated as a scheduled, priority activity rather than something done opportunistically when time allows. Dedicated review blocks — for example, 9:00 AM and 2:00 PM daily — are the most common implementation.

3. Use Stacked PRs Instead of Large Feature Branches

Stacked PRs — a pattern where each PR builds on the previous one rather than accumulating on a long-lived feature branch — allow review and feedback to happen incrementally. Rather than opening one 800-line PR at the end of a two-week feature, the developer opens four 200-line PRs across the two weeks, each of which gets reviewed and merged before the next is opened.

This approach keeps coding time short, keeps PRs in the reviewable size range, and eliminates the painful merge conflicts that accumulate on long-lived branches.

4. Automate Merge After Approval

If your team has not enabled auto-merge for approved PRs with passing CI checks, enable it. The gap between approval and merge — which should be near-zero — is pure waste when it is handled manually. GitHub's native auto-merge feature, or equivalent tooling in your CI system, eliminates this phase entirely for straightforward PRs.

5. Review Code in Dedicated Time Blocks

Code review is cognitively demanding work that suffers when done in fragmented, opportunistic windows. Teams that block out dedicated review time — separate from heads-down coding time — produce higher-quality reviews and have shorter pickup times because the activity is scheduled rather than reactive.

A common pattern is two review windows per day: one in the morning before deep work begins, and one in the early afternoon before the day's energy declines. This structure means no PR waits more than a few hours for a first look.

6. Use Draft PRs for Early Feedback

Draft PRs allow developers to share work-in-progress for structural feedback before the implementation is complete. This practice compresses review time on the final PR by resolving alignment issues — architectural concerns, API design questions, approach disagreements — before the code is written, not after.

Teams that use draft PRs effectively report fewer multi-round revision cycles on their final PRs, because the high-level feedback has already been incorporated during development.

7. Track and Visualize Your Cycle Time Weekly

What gets measured gets managed. Teams that review their cycle time metrics in their weekly engineering sync — discussing where time is going and what changed from the previous week — improve faster than teams that track metrics without reviewing them.

Gitrecap's Cycle Time dashboard provides a weekly snapshot of all four phases, trend lines, and individual PR outliers, making it easy to identify which phase is your current bottleneck and track whether interventions are working.

PR Cycle Time vs Lead Time — Understanding the Difference

These two metrics are related but measure different spans of the software delivery process, and conflating them leads to confusion about what is actually being improved.

PR cycle time covers the developer workflow: from the first commit on a branch to the point the PR is merged. It is a measure of how efficiently your team moves code through development and review. It is the right metric to discuss with developers and engineering managers focused on the mechanics of shipping code.

Lead time — as defined by DORA — covers the full span from when a change is committed (or in some definitions, when a ticket is created) to when it is deployed and running in production. Lead time includes PR cycle time, but also includes deployment pipeline duration, any staging or QA gates, change approval processes, and deployment scheduling.

Both metrics matter. Cycle time is the developer's lever — the part of the delivery process the engineering team controls directly. Lead time is the business lever — the end-to-end view that matters for product velocity, customer value delivery, and strategic planning. Improving cycle time is a prerequisite for improving lead time, but the two require different improvement strategies.

For a broader view of how cycle time fits into engineering performance measurement, see our guide on what are DORA metrics and how teams use them to benchmark delivery performance.

Start Tracking PR Cycle Time Automatically

The biggest barrier to improving cycle time is not knowing where time is actually going. Teams that guess — "we think pickup time is our bottleneck" — often invest effort in the wrong phase and see little improvement. Teams that measure know exactly which phase to address and can validate whether their interventions are working.

Gitrecap's Cycle Time dashboard connects to your GitHub repositories and automatically calculates all four cycle time phases for every merged PR. You get trend lines over time, per-author and per-repository breakdowns, and a scatter plot showing where individual PRs fall relative to your team's benchmarks.

Each point represents a single PR. Outliers above the trend line are instantly visible, making it easy to identify which PRs are driving your average cycle time up.

No scripts to write, no API keys to manage, no dashboards to maintain. Connect your repositories and your first cycle time report is ready within minutes.