Review Cycles

The average number of “changes requested” reviews a PR receives before it gets merged. Bucketed as 0 / 1 / 2 / 3+.

Family
Flow & Cycle Time
Cadence
Per PR, aggregated

At a glance

Review Cycles counts how many rounds of “changes requested” each PR went through. A PR merged with zero changes-requested reviews has 0 cycles (a clean first-pass). One round of “please fix X” before approval is 1 cycle. Two rounds is 2. Three or more is 3+.

It is one of the dashboard’s better diagnostic metrics — a high cycle count is almost always either too-big PRs, unclear specs, or mismatched author and reviewer expectations. Each of those has a different fix.

Formula

Formula
Review Cycles per PR = number of CHANGES_REQUESTED reviews before merge

Bucketed as 0 / 1 / 2 / 3+ for aggregate views

The PR record stores approved_at (the first APPROVED-review timestamp) and review_cycles (the count of CHANGES_REQUESTED reviews).

How GitKraken Insights calculates it

For each merged PR, the backend counts reviews with state CHANGES_REQUESTED that occurred before the PR was merged. That count is stored on the PR record as review_cycles.

For aggregate views (team-level, org-level), the metric is shown either as the mean number of cycles, or as the distribution across the four buckets (0 / 1 / 2 / 3+) as stacked bars or breakdown lines.

The buckets are the more useful presentation — they show the shape of the problem rather than just the average. A team averaging 1.0 cycles could be evenly distributed across the buckets or could be “everyone gets exactly 1 cycle.” Those need different fixes.

Why it matters

Review Cycles tells you about a few different problems at once:

Compared to Cycle Time, Review Cycles is more causal. Cycle Time tells you it took 5 days; Review Cycles tells you it took 5 days because of three rounds of back-and-forth.

How to read it

  • < 0.5Strong — most PRs go through clean. Code quality at submission is high.
  • 0.5 – 1.0Healthy — typical for orgs with good but not great PR discipline.
  • 1.0 – 2.0Fair — every PR averages a round of revisions. Look at PR size and spec clarity.
  • > 2.0Needs attention — chronic back-and-forth. PRs are likely too big, or specs are too thin.

The distribution matters as much as the mean. A team with 60% at 0 cycles, 30% at 1, and 10% at 3+ has a small problem cohort. A team with 50% at 0, 30% at 1, 15% at 2, 5% at 3+ has the same mean but a worse tail.

Settings that affect it

None. Review Cycles is a measurement.

How to improve it

Limitations and gotchas

FAQ

A team has high Review Cycles but low CFR. Are we just being too picky?

Possibly, but probably not. Thorough review catches real problems before they ship — high cycles + low CFR is the trade. The interesting question is whether the time cost of those cycles outweighs the bug-prevention value.

One developer’s PRs have 4× the cycles of the team average. Is that a performance issue?

Maybe, but check the work first. PRs in unfamiliar domains, big refactors, or risky changes naturally accumulate review feedback.

Does this count “approving but with suggestions” reviews?

No. Only formal CHANGES_REQUESTED reviews count.

Related metrics

Metric Relationship
First-Pass Rate The “0 cycles” percentage, expressed as a positive metric.
Cycle Time Long Review phase is usually high Review Cycles.
Effort Score High-effort PRs tend to have more review cycles. Track together.

Where it appears