Cycle time: what it is and how to improve it

Cycle time is the elapsed time from the moment a developer starts a change to the moment it is merged. DevPerform reports it as the median hours from PR open to merge for a period, using the median rather than the mean so a handful of stale pull requests don’t distort the picture.

On its own, a cycle-time number tells you what is slow but not why. The value comes from splitting it into phases, because a team stuck in review needs a completely different fix from a team stuck waiting for a first look.

DevPerform decomposes every merged PR into four sequential phases:

• Coding — first commit to PR opened. How long the change sat in progress before it was ready for review.
• Pickup — PR opened to first review (or to merge, if it’s never reviewed). This is the wait for a reviewer to engage, and it’s where most teams lose the most time.
• Review — first review to merged. The back-and-forth of feedback and revision. (DevPerform runs this phase to merge rather than to approval so it works identically across GitHub, GitLab, and Bitbucket.)
• Deploy — merged to deployed, when you connect a deploy signal.

Pickup and review always add up to the full open-to-merge cycle time, so you can see at a glance which half of the wait is hurting you.

LinearB’s 2026 benchmarks (8.1M+ pull requests across 4,800 teams) publish Elite / Good / Fair / Needs-focus bands for each phase. The elite marks are worth knowing as directional targets:

• Coding time — elite <54m, good 0.9–4h.
• Pickup time — elite <1h, good 1–4h.
• Review time — elite <3h, good 3–14h.
• Merge time — elite <1h, good 1–3h.

Treat these as context, not a verdict. Open-source projects, regulated industries, and deep-refactor work all sit legitimately outside the elite band. The point is the direction of travel and knowing which phase to attack first.

• Long coding time usually means changes are too big or the work wasn’t broken down. Smaller, well-scoped pull requests move faster (see PR size).
• Long pickup time is the highest-leverage fix for most teams: set a review SLA, cap work-in-progress so people finish reviews before starting new work, and route review requests to a channel people actually watch (see time to first review).
• Long review time points to oversized PRs, unclear acceptance criteria, or a review bottleneck on one or two people. Spread review load and keep changes small.
• Long deploy time is a pipeline problem — batch sizes, manual gates, or flaky CI. Deploying more often, in smaller batches, shortens it.

Cycle time answers “what’s slow.” To learn why, pair it with a short developer survey — the friction people report often explains the phase that’s dragging. DevPerform computes phased cycle time automatically from your GitHub, GitLab, or Bitbucket history (no agents, no CI changes) and reports it at the team level so the data stays candid and hard to game. You can run the free benchmark on any public repo to see all four phases scored against these bands in seconds.