Cycle Time Calculator
Calculate your PR cycle time breakdown. See where time is spent between coding, waiting for review, in review, and merging.
Cycle time is the elapsed time from the first commit on a change to the moment it merges. This calculator splits that span into four phases - coding, waiting for review, active review, and merge - so you can see exactly where the hours go instead of staring at a single aggregate number.
It is built for engineering leaders and team leads who suspect their delivery is slow but cannot point to why. Enter the hours each phase takes and the tool returns a performance tier for the total, a visual phase breakdown, and the single biggest bottleneck to fix first.
Enter Your Cycle Time Phases
Enter at least one phase duration above to see your cycle time analysis.
Next Steps to Reduce Cycle Time
- Break down large PRs. If your PRs regularly exceed 400 lines, split them by feature, layer, or logical boundary. Smaller PRs get reviewed faster and merge with fewer issues.
- Implement reviewer rotation. If waiting time exceeds 4 hours, assign primary and backup reviewers. Consider dedicated review windows or "review first" morning rituals.
- Automate the merge phase. If approved PRs sit for hours before merging, enable auto-merge on approval or implement merge queues to eliminate manual steps.
- Track trends, not snapshots. Cycle time varies by PR complexity. Track weekly averages over time to identify systemic improvements or regressions.
About Cycle Time
Cycle time measures how long it takes for code to go from development to production. It is a key indicator of team efficiency and is composed of four distinct phases, each representing a different stage in the development workflow.
Time from first commit to requesting review
Time waiting for first review
Time from first review to approval
Time from approval to merge
How it’s calculated
The total cycle time is the sum of four sequential phases. The tool adds the hours you enter, scores the total against delivery tiers, and flags the longest non-coding phase as your bottleneck.
The four phases
- Coding: from the first commit until the PR is opened for review. This varies by task complexity, so it carries no benchmark.
- Waiting for review: the PR is open but no reviewer has started. This is usually pure idle time.
- In review: from the first review action to approval. This is where back-and-forth and rework happen.
- Merge: from approval to merged. Short in healthy teams, a sign of process drag when long.
How the total is scored
Total cycle time = coding + waiting + review + merge. The total maps to a tier: under 24 hours is Elite, under 3 days is High, under 1 week is Moderate, and beyond a week needs work. Each measurable phase is also scored against its own threshold so you can see which stage drags the total down.
Finding the bottleneck
The tool compares the four phases and marks the largest one as the bottleneck. Coding can be the largest phase, but since it has no benchmark the tool steers you toward the longest reviewable phase - waiting, review, or merge - because those are the stages you can act on this week.
Data source
Pull the timestamps from your version control: first commit time, PR open time, first review time, approval time, and merge time. Average across 30 to 90 days of merged PRs so a single unusual change does not skew the picture.
Worked example
A team measures a typical PR: 8 hours of coding, 6 hours waiting for a reviewer to pick it up, 4 hours in active review, and 1 hour from approval to merge.
- Total cycle time is 8 + 6 + 4 + 1 = 19 hours, which lands in the Elite band of under 24 hours.
- Waiting for review is the largest non-coding phase at 6 hours, so it is flagged as the bottleneck.
- Waiting at 6 hours sits above the 4-hour Elite threshold for that phase, confirming it is the softest number.
The read: this team ships fast overall, but a third of the non-coding time is a PR sitting idle in a queue. A reviewer rotation or a morning "review first" ritual would trim that 6 hours toward the Elite mark and push an already strong cycle time lower without touching how anyone writes code.
Cycle Time Benchmarks
| Metric | Elite | High | Medium | Low |
|---|---|---|---|---|
| Total cycle time | Under 24 hours | 1-3 days | 3-7 days | More than 1 week |
| Waiting for review | Under 4 hours | Under 24 hours | 1-3 days | More than 3 days |
| In review | Under 4 hours | Under 24 hours | 1-3 days | More than 3 days |
| Merge (approval to merged) | Under 1 hour | Under 4 hours | 4-24 hours | More than 1 day |
Coding time carries no benchmark - it varies with task complexity.
Our Take
Cycle time is the most actionable metric - unlike deployment frequency or change failure rate, you can directly influence it through better PR practices.
Deployment frequency depends on release processes and organizational readiness. Change failure rate requires production monitoring infrastructure. But cycle time? You can improve it tomorrow by splitting that 800-line PR into three focused changes. The best part: improving cycle time naturally improves the other DORA metrics too.
"PRs under 200 lines merge 40% faster than PRs over 500 lines."
— Google and Microsoft code review efficiency benchmarks
Key terms
- Cycle Time
- The elapsed time from the first commit on a change to the moment it merges. It measures engineering throughput, distinct from the wider lead time that includes planning.
- Waiting for Review
- The stretch where a PR is open but no reviewer has started. It creates no value and is usually the largest single source of waste in the cycle.
- In Review
- The active phase from the first review action to approval, covering reviewer comments, author responses, and any rework.
- Bottleneck
- The phase that consumes the most time and therefore caps how fast the whole cycle can run. Fixing it yields the biggest reduction in total cycle time.
- Performance Tier
- The Elite, High, Moderate, or Needs Work band a total cycle time falls into, based on delivery benchmarks for engineering teams.
Frequently Asked Questions
PR cycle time measures the total time from when a developer starts coding a change until it's merged into production. It matters because shorter cycle times enable faster feedback loops, reduce context-switching costs, and allow teams to ship value to users more quickly. Research shows that elite teams have cycle times under 24 hours, while struggling teams often exceed a week - that's a 7x difference in time-to-value.
Want to track this automatically?
CodePulse connects to your GitHub and calculates these metrics in real-time. No more manual data entry or spreadsheets.
Free tier available. No credit card required.
See These Features in Action
Break down cycle time into coding, waiting, review, and merge phases.
Predict delivery timelines based on historical velocity trends.
Related Tools
Meeting Cost Calculator
See the true cost of meetings for your engineering team. Calculate how much engineering time and money is spent in meetings.
Code Review Time Estimator
Estimate how long code reviews should take based on PR size and complexity. Set realistic review SLAs for your team.
Team Capacity Planner
Calculate your team's actual coding capacity. Account for meetings, holidays, and other overhead to plan sprints realistically.