Merge time

Pull requests sitting in review for days are one of the most common signs that your delivery pipeline has a hidden bottleneck. Merge time measures how long a pull request takes to go from first review request to the moment it is merged into the target branch. When merge time is high, your squad's work piles up, integration risk grows, and sprint commitments start to slip before anyone notices why. This page covers the definition, how to measure it, benchmarks, how to improve it, and how DevStats surfaces it automatically.

Key takeaways

• Merge time measures how long a pull request waits between review request and merge. It is one of the clearest signals of flow efficiency in your delivery pipeline, because it captures time that code is ready but not yet integrated, which directly delays your squad's ability to ship.
• Merge time is calculated as: Merge time = timestamp of merge minus timestamp of first review request. No published DORA benchmark exists for merge time specifically, but elite teams typically merge pull requests in under four hours. Anything consistently above 24 hours warrants investigation.
• The most common mistake teams make is treating merge time as a measure of reviewer effort rather than a signal about the review process itself. Long merge times usually point to structural issues: PR size, unclear ownership, or review queue depth, not individual reviewer speed.
• DevStats tracks merge time automatically by connecting to your Git provider, with benchmarks against 1,000+ engineering teams so you can see where your squad stands. Start a free trial to see your numbers in under two minutes.

Merge time definition

Merge time is the amount of time a pull request spends between being opened for review and being merged into the target branch. It measures how quickly reviewed code moves from ready state to integrated state, making it a direct indicator of flow efficiency in your development process.

Technically: Merge time = merge timestamp minus review-request timestamp, measured per pull request and typically reported as a median or 85th-percentile across a time window. It sits inside the broader PR cycle time, which also includes time to first review and time to deploy. When merge time is high relative to total cycle time, the bottleneck is in the review and approval stage, not in coding or deployment. Slow merge time translates directly into delayed releases and compounding integration risk, both of which affect your stakeholders' confidence in your squad's delivery predictability.

Why merge time matters for engineering teams

Squads that do not track merge time often discover problems too late. A PR that sits for three days before merging can block dependent work, create merge conflicts for other players, and push features past a sprint boundary without any single point of failure being visible in a standup or retrospective. By the time the delay shows up in missed commitments, the root cause is already buried.

For engineering leaders, merge time connects directly to delivery velocity, sprint predictability, and developer experience. Players who regularly see their work sit in review queues lose momentum and context. That context-switching cost is real, and it compounds across a squad. Teams with consistently low merge time tend to ship more predictably and maintain higher throughput over time, because code moves through the pipeline without accumulating.

Within the DORA framework, merge time is a component of the lead time for changes metric, one of the four key indicators of software delivery performance. Measuring it is the starting point. The engineering manager is the one who interprets the pattern and decides what to change.

How to measure merge time

To calculate merge time, you need timestamps from your Git provider: specifically, when a pull request was opened or marked ready for review, and when it was merged. Most teams pull this from GitHub, GitLab, or Bitbucket via API or a connected analytics tool. You do not need your CI/CD pipeline or issue tracker to measure merge time in isolation, though pairing it with code review data gives you much more diagnostic value.

Report merge time as a median across all PRs in a given period, and separately track the 85th percentile to catch outliers. A median of two hours with a p85 of 48 hours tells a different story than a median of six hours with a p85 of eight hours. No official DORA benchmark exists for merge time as a standalone metric, but patterns from high-performing teams suggest the ranges below. Benchmarks vary by team size, codebase complexity, and release model, so use these as directional signals, not hard targets. DevStats's benchmarks feature lets you compare your squad's merge time against teams of similar size and stage.

Merge time in practice: a real example

A VP of Engineering at a 40-person SaaS company noticed that sprint completion rates had been slipping for two consecutive quarters, but individual task estimates looked reasonable. After pulling merge time data, she saw that the median was 18 hours, with a p85 of four days. Digging into the distribution, she found that PRs over 400 lines of diff accounted for nearly 70% of the long-tail delays. Reviewers were not slow; they were deprioritizing large, complex PRs in favor of smaller ones they could turn around quickly.

She introduced a squad norm: PRs over 300 lines required a brief async summary comment from the author before review. She also set a soft limit on PR size and tracked it weekly in the team's sprint review. Within six weeks, median merge time dropped to under eight hours and sprint completion rates recovered. She used the data to identify the pattern; the decision and the norm were entirely hers.

How to improve merge time

1. Reduce PR size. Large PRs are the single biggest driver of long merge times. Set a squad norm of 200 to 400 lines of diff per PR. Smaller PRs are faster to review, easier to understand, and generate fewer back-and-forth comments. Watch your review comment volume as a leading indicator: high comment counts on large PRs are a reliable early warning sign.
2. Define explicit review SLAs. If your squad has no shared expectation about how quickly a review should happen, delays become invisible. Set a target, for example, first response within four hours during working hours, and make it visible in your team's working agreement. Track it using your code review data to see whether the norm is holding.
3. Assign reviewers at PR creation. Unassigned PRs sit. Auto-assignment rules in GitHub or GitLab eliminate the ambiguity of who is responsible. Pair this with a collaboration view to understand whether review load is distributed evenly across the squad or concentrated on a few players.
4. Audit your approval requirements. Required approvals from multiple senior engineers on every PR create structural bottlenecks. Review your branch protection rules and ask whether every approval gate is genuinely reducing risk or just adding latency. Reserve multi-approver requirements for high-risk paths like infrastructure or security changes.
5. Surface stale PRs in standups. PRs that have been open for more than 24 hours without activity should be a standing agenda item. DevStats's activity heatmap can help you spot periods of low review activity across the squad, giving you the data to have a focused conversation rather than a general one.

Merge time vs. PR cycle time

Merge time and PR cycle time are related but measure different spans of the review process. PR cycle time captures the full journey of a pull request from first commit to merge, while merge time covers only the review and approval phase.

Use merge time when you want to isolate whether the review process is the bottleneck. Use PR cycle time when you want to understand the full cost of delivering a unit of work through your pipeline.