PR Cycle Time: The Metric That Reveals How Your Team Really Works

2026-06-20 · 8 min read · GitHub & Metrics

If you could only track one engineering metric, PR cycle time would be a strong candidate. Not because it's the most complete signal, but because it's the most actionable — and because what it reveals about a team is surprisingly deep.

PR cycle time is the time from when a pull request is opened to when it's merged. Simple to measure. But the number hides a story about how your team communicates, how healthy your codebase is, and where the real bottlenecks are.

What Cycle Time Actually Measures

A PR sits in one of four states before it's merged:

  1. Waiting for review — the PR is open, no one has looked at it
  2. Under review — someone is actively reviewing
  3. Changes requested — author is revising based on feedback
  4. Waiting for CI — builds, tests, checks running

Most teams assume their cycle time is high because their engineers write slow code. Almost always, the problem is in state 1: PRs sitting unreviewed for hours or days.

This matters because waiting is invisible. When an engineer is writing code, you can see progress. When a PR is waiting for review, it looks like nothing is happening — but a human is context-switching, losing momentum, and often picking up new work that adds to WIP. Every unreviewed PR is a small cost that compounds.

Benchmarks

What does good look like? Industry benchmarks from DORA research:

Most teams are surprised to discover where they fall. A team that feels fast often has a median cycle time of 3–5 days once you measure it.

Reading Your Cycle Time Data

Raw cycle time is a starting point. The more useful question is: where is time being spent?

Long time-to-first-review signals a review culture problem. PRs aren't being picked up promptly. This could be because reviewers don't feel responsible for it, reviews aren't prioritised over writing code, or PRs are too large to pick up quickly.

Long review-to-merge after approval signals a process problem — usually CI flakiness, slow pipelines, or manual deployment steps.

Many round trips (3+ review cycles) signals either an unclear PR description, misaligned expectations about quality, or a reviewer who gives feedback in batches rather than holistically.

High variance across team members signals uneven workload. One person getting code reviewed in 4 hours while another waits 3 days means your review load isn't distributed well.

The PR Size Problem

The single biggest lever on cycle time is PR size. Large PRs sit longer because:

Track mean PR size (lines changed) alongside cycle time. If your PRs average 500+ lines changed, that's almost certainly contributing to slow cycle times regardless of other factors.

The target for most teams: PRs under 200 lines changed, with a clear, single purpose. Some teams use 400 as the threshold. Anything over 800 is almost always a problem.

Using Cycle Time in 1:1s

Cycle time data is most useful not as a performance metric but as a conversation starter. In 1:1s:

"I noticed your PRs are sitting unreviewed for an average of 3 days before someone picks them up. Is that a problem you're experiencing? What's the impact on your work?"

or

"Your review turnaround is really fast — you're typically reviewing within 4 hours. I wanted to call that out because it makes a real difference to the rest of the team."

This is different from using the number as a grade. The goal is to surface what's actually happening and have a human conversation about it.

What Slows Code Review Down

The things that slow code review down, roughly in order of impact:

  1. PRs are too large — reviewers avoid them
  2. No clear ownership of review — everyone assumes someone else will do it
  3. Async communication delays — reviewer asks a question, waits 6 hours for an answer
  4. Unclear PR descriptions — reviewer spends 20 minutes understanding context they shouldn't have to
  5. CI flakiness — engineers re-run tests instead of fixing them
  6. Perfectionism in review — every PR generates 15 nitpicky comments that create noise and delay

Most of these are fixable with team agreements rather than tooling.

Building a Review Culture

Teams that have fast cycle times usually share a few practices:

Reviews are first-class work. Reviewing code is not an interruption to "real work" — it's part of the job. Teams that treat reviews as optional or secondary have slow cycle times.

There's a response SLA. Many high-performing teams have an informal (or explicit) agreement: reviews get a first response within 2–4 hours during the workday. Not necessarily a full review — just a signal that you've seen it.

PRs have good descriptions. Authors write what changed, why, and how to test it. This isn't optional. A PR without context forces the reviewer to reverse-engineer the intent, which takes longer and produces worse feedback.

Blocking vs non-blocking comments are distinguished. "This must change before merge" vs "this is a suggestion you might consider" are different things. Teams that don't distinguish between them create confusion about when a PR is actually ready.

The Right Way to Use This Metric

PR cycle time is a health indicator, not a performance rating. Using it to rank engineers or create pressure to "go faster" is a misuse that usually backfires — engineers start splitting PRs artificially or skipping test coverage to hit a number.

The right use is diagnostic: what does this tell us about how we work, and where's the friction? Once you've identified the friction, the metric becomes a way to track whether your interventions are actually helping.

Teams that measure cycle time and discuss it openly tend to improve it naturally — not because of pressure, but because visibility creates shared accountability.