What Is PR Cycle Time? How to Measure and Improve Pull Request Speed

PR cycle time is the total elapsed time from a developer's first commit on a branch to the pull request being merged into the target branch. It captures every phase of the code change lifecycle: writing the code, waiting for a reviewer, going through review, and merging. PR cycle time is the single most actionable metric for understanding how fast your engineering team delivers code changes, because it exposes exactly where time is being spent and where bottlenecks form.

Unlike broader metrics like DORA's change lead time (which extends to production deployment), PR cycle time focuses specifically on the code review and collaboration process. This makes it directly actionable for engineering teams. You cannot always control deployment pipelines or release schedules, but you can control how fast code moves through review.

Long cycle times also cost more than calendar days: the author context-switches while waiting, the branch drifts from main, and reviewers come back to a change they no longer remember.

How Do I Reduce Pull Request Cycle Time?

Reduce the wait, not the work: most cycle time is a PR sitting in a queue, so ship smaller PRs, get a review on every PR within minutes, auto-approve the low-risk ones, and merge automatically once checks pass. Macroscope covers the review side of that list on GitHub:

• Automated first-pass review. Macroscope reviews every PR as it opens, so the author gets bug findings during what would otherwise be pickup wait. See how to reduce PR cycle time with AI code review.
• PR summaries. Macroscope writes a summary into the PR description, so a reviewer can pick the change up cold. See what is a PR summary.
• Auto-approval for low-risk PRs. Approvability approves PRs that pass a written policy and a correctness check, and escalates the rest. Pydantic auto-approves about 91% of its PRs this way and went from 100–150 merged PRs a week to about 500 (case study).
• Fewer review rounds. Reply "fix it for me" on a finding and Fix It For Me opens a fix PR and iterates until CI passes.

The process levers matter as much as the tooling: small PRs, a review SLA, spread-out review load, and auto-merge. The phase-by-phase tactics are below.

What Are the Four Phases of PR Cycle Time?

PR cycle time breaks down into four distinct phases, each driven by different factors and improved by different strategies.

1. Coding Time

Coding time is the period from a developer's first commit to opening the pull request. This is the time spent writing code, running local tests, and preparing the change for review. It is the phase where the developer is in control.

Coding time is often the least problematic phase, but it can be inflated by unclear requirements, excessive scope, or the developer's hesitation to open a PR until the code is "perfect." Teams that practice draft PRs and early feedback tend to have shorter coding times because developers share work in progress rather than polishing in isolation.

2. Pickup Time

Pickup time is the period from when a pull request is opened (or marked ready for review) to when the first reviewer leaves a comment or starts reviewing. This is pure wait time. The developer has finished their work and is blocked until someone looks at it.

Pickup time is frequently the largest contributor to long cycle times. Look at the tail as well as the median: if your P90 pickup time is 48 hours, one in ten PRs sits for two full days before anyone looks at it.

The causes are predictable: reviewer overload (a few senior engineers review most PRs), timezone gaps in distributed teams, and the absence of clear review assignment or SLA expectations.

3. Review Time

Review time is the period from first review activity to the final approval. It includes all review cycles: initial comments, author responses, follow-up reviews, and eventual approval. This phase captures the back-and-forth collaboration between author and reviewer.

Review time is influenced by PR size, code complexity, and the clarity of the change. A well-scoped PR with a clear description and small diff gets approved quickly. A sprawling PR with 800 changed lines and no description triggers multiple rounds of clarification.

4. Merge Time

Merge time is the period from final approval to the PR being merged. In many teams, this phase is near-instant because developers merge immediately after approval. But in teams with merge queues, required CI checks after approval, or manual merge processes, this phase can add hours or days.

Merge time also increases when PRs develop merge conflicts after approval. If main has moved significantly since the PR was approved, the author may need to rebase, re-run CI, and sometimes get re-approval.

What Are Good PR Cycle Time Benchmarks?

There is no single published standard for PR cycle time. Targets vary by team size, codebase complexity, and industry, so treat the table below as rule-of-thumb starting points and set your own from your current baseline.

Phase	Elite	Good	Needs Improvement
Coding Time	Less than 1 day	1-3 days	More than 5 days
Pickup Time	Less than 2 hours	2-12 hours	More than 24 hours
Review Time	Less than 4 hours	4-24 hours	More than 48 hours
Merge Time	Less than 1 hour	1-4 hours	More than 24 hours
Total Cycle Time	Less than 1 day	1-3 days	More than 5 days

Elite teams consistently merge PRs within the same business day they are opened. The key driver is not faster coding. It is dramatically shorter pickup and review times, which come from smaller PRs, clear ownership, and systematic review practices.

The targets also reflect an important pattern: in many teams, total cycle time is dominated by wait time, not work time. When you break your own data down by phase, check how much of it is pickup and merge wait. Developers are rarely slow. The process around them often is.

How Do You Measure PR Cycle Time?

Measuring PR cycle time accurately requires data from your version control system (GitHub, GitLab, or Bitbucket) and a clear definition of each phase boundary.

First commit timestamp marks the start of coding time. This comes from the git history of the PR's branch.

PR opened timestamp marks the end of coding time and the start of pickup time. For teams that use draft PRs, use the "ready for review" timestamp instead of the "opened" timestamp to avoid counting draft time as pickup time.

First review activity timestamp marks the end of pickup time and the start of review time. This is the timestamp of the first comment, review, or approval from a reviewer (not the PR author).

Final approval timestamp marks the end of review time and the start of merge time.

Merge timestamp marks the end of the entire cycle.

Measurement Pitfalls

Counting weekends and after-hours. If a PR is opened at 5 PM Friday and reviewed at 9 AM Monday, the raw pickup time is 64 hours. But the effective pickup time is closer to 1 hour of the next business day. Decide whether you measure calendar time or business hours, and be consistent.

Ignoring draft PRs. If developers open draft PRs for early feedback, counting from "PR opened" inflates coding time and deflates pickup time. Use "marked ready for review" as the boundary.

Averaging instead of using percentiles. A team's average cycle time can look healthy while a significant tail of PRs takes over a week. Track P50 (median), P75, and P90 to understand the full distribution. The P90 often reveals systemic issues that the median hides.

Not segmenting by PR size. A 10-line bug fix and a 500-line feature refactor have fundamentally different expected cycle times. Benchmark and track cycle time by PR size category (small, medium, large) for meaningful comparisons.

How Do You Improve Each Phase of PR Cycle Time?

Reducing Coding Time

Keep PRs small. One of the most effective practices is breaking work into small, focused pull requests. Small PRs are easier to review in one pass and easier to roll back. If a feature requires 1,000 lines of changes, ship it as a series of smaller PRs rather than one monolith.

Use draft PRs for early direction checks. Open a draft PR after the first meaningful commit to get early feedback on approach before investing hours in implementation. This catches "wrong direction" issues early, when they are cheap to fix.

Write clear PR descriptions. A well-written PR description reduces review time by giving reviewers context upfront. Include what changed, why it changed, and how to verify it, or let a tool write the PR summary for you.

Reducing Pickup Time

Set review SLAs. Establish a team norm for maximum pickup time, such as "all PRs get first review within 4 business hours." Without an explicit expectation, reviews get deprioritized indefinitely.

Distribute review load. If two engineers review 70% of PRs, your team has a structural bottleneck. Use CODEOWNERS files and automated review assignment (round-robin or load-balanced) to spread reviews across the team. Tools like GitHub's auto-assign and review routing features make this systematic.

Create review time blocks. Encourage the team to check for pending reviews at specific times, such as morning and after lunch. This creates a predictable cadence without requiring constant context switching.

Automate the first pass. AI code review tools can provide immediate feedback on a PR within minutes of opening. This does not replace human pickup, but it gives the author useful feedback during what would otherwise be dead wait time. Macroscope reviews every pull request as it opens, so the author can fix real bugs before a human reviewer engages, which reduces the impact of pickup delays.

Reducing Review Time

Review small PRs quickly. Small PRs (under 100 lines) should take a single review pass. If a small PR requires multiple review rounds, it often means the PR scope was fine but the author and reviewer have misaligned expectations that need a conversation, not more review cycles.

Use inline suggestions. Instead of leaving a comment that says "this variable name should be more descriptive," leave a GitHub suggestion with the actual renamed variable. The author can accept it with one click rather than making a new commit.

Resolve discussions promptly. Open review threads that go unresolved for days are a common source of review time inflation. Authors should respond to all review comments within the same day. Reviewers should re-review promptly after the author addresses feedback.

Reducing Merge Time

Auto-approve low-risk PRs. Docs, tests and simple fixes often wait in the same queue as risky changes. A policy-based check such as Approvability approves the safe ones and sends the rest to a human.

Enable auto-merge. GitHub, GitLab, and Bitbucket all support auto-merge, which merges the PR automatically when all required checks pass after approval. This eliminates the delay between approval and someone remembering to click the merge button.

Use merge queues. For repositories with high commit velocity, merge queues (GitHub Merge Queue, Mergify, or Bors) test PRs against the latest main branch before merging, preventing broken builds without requiring manual rebasing.

Minimize required checks after approval. If your CI pipeline takes 45 minutes and must re-run after every rebase, merge time will always include at least one CI cycle. Optimize CI speed, or use merge queues that batch CI runs.

How Does PR Cycle Time Relate to Other Engineering Metrics?

PR cycle time is one component of the broader DORA metric "change lead time" (formerly "lead time for changes"), which measures from commit to production deployment. See what are DORA metrics for all five. PR cycle time captures the code review portion. Deployment pipeline time captures the rest.

PR cycle time also correlates with several other important metrics:

Deployment frequency. Teams with fast cycle times can deploy more often because code moves through the pipeline faster, even without changes to deployment infrastructure.

Developer satisfaction. Waiting on review is a common frustration for engineers, which is one reason the SPACE framework puts satisfaction next to activity and efficiency.

Defect rate. Faster cycle times do not have to mean more defects. Fast review usually comes from smaller PRs and fresher reviewer context, and a short-lived branch has less time to diverge from main.

Track these together rather than in isolation, so a faster cycle time that comes with a worse change fail rate shows up as a trade-off, not a win.

Frequently Asked Questions

How do I reduce pull request cycle time?

Cut the wait time, which is usually most of the cycle. Ship smaller PRs, set a review SLA, spread review load with CODEOWNERS and auto-assignment, and turn on auto-merge. On the tooling side, Macroscope reviews every PR as it opens, writes a PR summary into the description so reviewers can pick it up cold, auto-approves low-risk PRs through Approvability, and opens fix PRs with Fix It For Me. Pydantic went from 100–150 merged PRs a week to about 500 after auto-approving about 91% of its PRs.

What is a good PR cycle time for a startup versus an enterprise?

Startups usually have shorter cycle times because teams are small, communication is fast, and process overhead is low. Enterprise teams usually run longer because of compliance requirements, larger teams with specialized reviewers, and more complex CI/CD pipelines. Both can improve, but set targets from your own baseline rather than a cross-company number.

Should we count bot-generated PRs in our cycle time metrics?

No. Dependabot updates, automated formatting fixes, and other bot-generated PRs have fundamentally different characteristics than human-authored PRs. Including them distorts your metrics. Track them separately if you want to monitor bot PR efficiency, but exclude them from team cycle time analysis.

How does PR size affect cycle time?

Larger PRs take longer at every phase: reviewers put them off, review takes more rounds, and the branch has longer to drift from main. Segment your own cycle-time data by PR size to see the effect on your team. Reducing PR size is one of the most effective ways to reduce cycle time.

Is it better to optimize for cycle time or review thoroughness?

It is often a false trade-off. Small, focused PRs are both faster to review and easier to review carefully than large, overwhelming ones, so reducing PR size improves speed and thoroughness together.

How do timezone differences affect PR cycle time?

Timezone gaps directly inflate pickup time. A PR opened at end-of-day in one timezone may not get reviewed until start-of-day in another, adding most of a day of wait time. Strategies to mitigate this include overlapping review windows, automated first-pass review to provide immediate feedback, and structuring teams so that most PRs can be reviewed within a single timezone.