PR Review Cycles
Last updated: October 27, 2026
PR Review Cycles counts how many times a merged pull request (PR) went back and forth between its author and reviewers before it merged. The page shows the average across PRs, capped at 8 cycles per PR.
Why it matters
A few rounds of feedback are healthy. Many rounds usually point to unclear requirements, large PRs, or review standards the author didn't know. Fewer cycles tend to mean clearer expectations and faster merges. Use the metric to find friction, measure the effect of process changes, and spot PRs that should have been split. The goal isn't zero iteration; it's efficient, high-quality review.
How it works
For each PR, Span builds a timeline of three kinds of events:
Feedback: a review in "commented" or "changes requested" state, and any PR comment, from someone other than the author.
Approval: a review in "approved" state from someone other than the author.
Commit: each non-merge commit on the PR, timed by its author date.
Span drops events from bots, coding agents set up as dev agents, and ignored Git usernames, then counts:
Review Cycles = (1 for the first approval) + (1 for each commit whose previous event was feedback)Later approvals add nothing. A run of several commits after one round of feedback counts once. A PR with no qualifying events scores 0.
Aggregations. The default Trimmed Average caps each PR at 8 cycles before averaging, so one PR with very many rounds can't skew the team number. Median, 75th Percentile, 90th Percentile, and Max use raw values.
Aggregation | When to use it |
|---|---|
Trimmed Average (cap 8) | Overall team health |
Median | The typical PR experience |
75th Percentile | Upper-middle of the range |
90th Percentile | Finding outliers |
Max | The single PR with the most cycles |
Reference ranges. Lower is better. A healthy target for most teams is 1.5 to 2.5.
Average | Assessment |
|---|---|
0.5 to 1.5 | Excellent: minimal back-and-forth |
1.5 to 2.5 | Good: a normal, healthy review process |
2.5 to 4.0 | Attention needed: look at the causes |
Over 4.0 | Action required: high friction |
Setup
No setup is needed once a Git integration is connected. Find the metric in:
Insights → Productivity → Quality → Code review.
Team and person pages, where it shows each person's cycles as a PR author.
AI impact comparisons and custom dashboards.
The PR scatterplot shows each PR's cycle count. Filter by team, person, IC level, job family, location, tenure, and repository, and use the All / Cross-Team toggle to keep only PRs with at least one cross-team review.
Things to know
Worked example: a reviewer comments, the author pushes two commits, the reviewer requests changes, the author pushes once, and the reviewer approves. Cycles = 1 (commits after the comment) + 1 (commit after changes requested) + 1 (approval) = 3.
Trimmed Average example: PRs with 1, 2, 1, 3, 15, 2, and 1 cycles count as 1, 2, 1, 3, 8, 2, and 1. The Trimmed Average is 18 ÷ 7 = 2.57 cycles.
Approved on first look scores 1. A PR merged with no review scores 0 and still counts, which lowers the average.
Every comment is feedback: any comment from someone other than the author counts, including a "thanks" reply. Comments that match your Ignore PR Comments phrases in Settings → Metrics still count here.
Commit timing uses author dates: a commit written before the feedback but pushed after it doesn't count as a response. A rebase usually keeps author dates, so the count stays the same. Squashing commits on the branch reduces the commits Span sees and can lower the count.
Edited comments: Span places a comment by its last-updated time. Editing an old comment after a later commit can move it in the timeline and add a cycle.
Which PRs count: merged PRs by developer contributors, outside ignored repositories and branches, placed on their merge date. Open and closed-unmerged PRs don't count.
Count, not speed: this metric doesn't measure time per cycle. Use Review Response Time for reviewer speed and the Reworking stage in PR Lifecycle for elapsed back-and-forth time.
Read it in context: large PRs, complex refactors, new reviewer rotations, and onboarding periods naturally raise cycles. Compare with PR Size before acting.
Related articles
Review Response Time (Average)
Need help?
Contact your Span account team or reach out to support@span.app.