Skip to main content
Cycle Time

PR Cycle Time

Written by James McGill
Updated over a week ago


The time between when the first commit is authored to when a pull request is merged.

Cycle Time starts at the first commit on the branch — not when branch is created.

Why it matters

PR Cycle Time represents your team’s time-to-market, or how quickly software is delivered to customers. Low PR Cycle Time often equates to higher output and more efficient teams. It is also correlated with higher stability, giving your team the ability to quickly respond to issues with change.

How to use it

You can treat PR Cycle Time as your speedometer. Use it to understand baseline productivity, and check any major change in processes against this to make sure it had a positive (or perhaps non-negative) effect on productivity.

We recommend setting a Decrease pull request cycle time target for each team. These targets are set based on the percentage of PRs that achieve a Cycle Time below a configurable threshold. Therefore, while the targets can help detect a slow process caused by any of a wide variety of SLDC issues, they will not be disproportionately affected by a small number of outliers. We suggest aiming for 80% of PRs with a cycle time of 16 business hours or less; more than 25% of Velocity users achieve that level of performance.

This metric is not diagnostic, so to identify why PR Cycle Time is low, you’ll want to look at metrics that make up smaller components of the software development process, such as Time to Open, Time to First Review, and Time to Merge.


The median organization averages a Cycle Time of 83 hours. The fastest quarter of organizations average less than 58 hours, while the slowest quarter average more than 124 hours.


Why is my PR Cycle Time so high?

Generally, PR Cycle Time is expected to be calculated from the time a PR is opened to when it is closed. For example:

  • I open a PR on Monday, September 12, and close it on September 13

  • I'd expect PR Cycle Time to be no more than 24 hours

However, there are actions that might influence PR Cycle Time to be much higher. Typically, this is caused by rebasing the PR.

When a PR is rebased, instead of looking at when the PR was opened, we look at when the first commit from the rebasing history was made. In some cases, the first commit might have been made well prior to when the PR was opened, causing PR Cycle Time to be much higher than expected.

To find the earliest commit associated with a PR, use the following git commands:

To see the exact date of the first commit in a branch called "Branch," use the following git command:

$ git log master..BRANCH --format=reference --reverse --date=iso | head -n1

To see how long ago the first commit was made in a branch called "Branch," use the following git command:

git log master..BRANCH --format=reference --reverse --date=relative | head -n1
Did this answer your question?