Skip to main content
Review Cycles
Written by James McGill
Updated over a week ago


The number of times a pull request goes back and forth between the author and a reviewer.


A review cycle is a comment, request for change or approval by someone other than the PR author. The cycles increment when there is a back and forth between the reviewer and the author. For example:

  • I open a PR and merge it without any interaction from anyone else, that’s 0 review cycles.

  • I open a PR and you approve it, that’s one review cycle.

  • I open a PR you leave a comment, I make another commit to fix it, then you approve it, that’s 2 review cycles.

  • I opened a PR, and no one made any edits or changes; that still counts as 0 review cycles.

Why it matters

Each time a pull request is passed back and forth, developers are required to context switch and spend more time on one particular line of work. If this happens frequently, the review process can become a bottleneck and demotivate engineers who are trying to complete their work.

How to use it

Review Cycles can indicate trouble when it is too high or when it is too low. Averaging more than 1.5 Review Cycles can mean that PRs are too large, being nitpicked, or lack adequate communication and planning before code is written. On the other hand, averaging less than 1.0 Review Cycles could indicate that too many PRs are being merged without review.

The Review Cycles histogram in the PR Resolution module can help you check if you are hitting the "sweet spot" of 1 or 2 cycles on most PRs.


The median organization averages 1.2 Review Cycles. The bottom tenth of organizations average less than 0.7 Review Cycles, while the top tenth average more than 1.5 review cycles.

Did this answer your question?