If you could only track one engineering metric, make it PR cycle time. This guide explains how to measure it, what benchmarks to aim for, and proven strategies to improve it.
Cycle time measures how long it takes for code to go from the first commit to merged and deployed. It captures the entire journey: development, code review, iteration, and integration.
Unlike vanity metrics like lines of code or commit counts, cycle time directly correlates with how fast you're delivering value to users.
Anatomy of Cycle Time
PR cycle time isn't a single number—it's the sum of several stages, each of which can become a bottleneck.
Coding Time
Time from first commit to PR opened. This is how long the developer spent writing the initial implementation.
Pickup Time
Time from PR opened to first review. This is how long the PR sat waiting for someone to look at it. In many teams, this is the biggest bottleneck.
Review Time
Time spent in active review. Back-and-forth between author and reviewers, with commits addressing feedback.
Merge Time
Time from final approval to merge. Usually short, but can be delayed by merge conflicts, CI failures, or deployment freezes.
Why Each Stage Matters
Long Coding Time
Could indicate the work was poorly scoped, the developer struggled with the implementation, or they're gold-plating beyond requirements.
Ask: Is this PR too big? Should it be broken down?
Long Pickup Time
The most common bottleneck. PRs sit in a queue because reviewers are busy, don't feel ownership, or aren't aware the PR exists.
Ask: Do we have a review rotation? Are notifications working? Is the team too siloed?
Long Review Time
Multiple rounds of feedback can be healthy (thorough review) or unhealthy (unclear requirements, perfectionist reviewers, lack of coding standards).
Ask: Are we reviewing for the right things? Do we have clear code standards? Are requirements clear before coding starts?
Long Merge Time
Usually indicates CI/CD issues: flaky tests, slow pipelines, or manual deployment gates.
Ask: Is our CI reliable? Are merges blocked on non-code factors?
What "Good" Looks Like
Benchmarks vary by company size and codebase complexity, but here's a rough guide:
| Stage | Elite | Typical | Slow |
|---|---|---|---|
| Coding | < 1 day | 1-3 days | > 1 week |
| Pickup | < 4 hours | 4-24 hours | > 2 days |
| Review | < 1 day | 1-3 days | > 1 week |
| Merge | < 1 hour | 1-4 hours | > 1 day |
| Total | < 2 days | 3-7 days | > 2 weeks |
If your median cycle time is under 2 days, you're in excellent shape. If it's over 2 weeks, you have significant room for improvement—and it's almost certainly costing you velocity.
Improving Cycle Time
Break Down Large PRs
The #1 predictor of slow cycle time is PR size. Large PRs are harder to review, take longer to get feedback, and are more likely to have merge conflicts.
Aim for PRs under 400 lines. If it's bigger, ask: can this be shipped incrementally?
Institute Review SLAs
Set a team agreement: all PRs get a first review within 4 hours (or by end of day). Make it visible who's waiting. Create accountability without blame.
Dedicate Review Time
If PRs languish because everyone's heads-down on their own work, schedule review blocks. 30 minutes in the morning, 30 after lunch. It's an investment that pays back in faster team velocity.
Automate the Boring Stuff
Use linters and formatters to catch style issues. Use automated tests to catch bugs. The less humans have to review, the faster reviews go.
Track and Discuss
Put cycle time on your team dashboard. Review it in retrospectives. When it spikes, investigate why. Celebrate when it improves.
Tracking in Velocinator
Velocinator calculates cycle time automatically from your GitHub data. For every PR, we break down:
- First commit timestamp
- PR opened timestamp
- First review timestamp
- All review rounds
- Final approval timestamp
- Merge timestamp
You can view cycle time by team, by repository, by individual contributor, or across your entire organization. Filter by time period to spot trends.
The goal isn't to obsess over the numbers. It's to make the invisible visible, so you can have better conversations about how your team works.
Frequently Asked Questions
- What is PR cycle time?
- PR cycle time measures how long it takes for code to go from the first commit to merged and deployed. It captures the entire journey: development, code review, iteration, and integration.
- What is a good PR cycle time?
- Elite teams achieve median cycle times under 4 hours. Most healthy teams fall in the 12-24 hour range. Anything consistently over 3 days indicates significant bottlenecks worth investigating.
- How do I reduce PR cycle time?
- Keep PRs small (under 400 lines), set team review SLAs, batch review sessions, speed up CI pipelines, and fix flaky tests. Measure each stage separately to find your specific bottleneck.
