Review Response Time (Average)
Last updated: October 27, 2026
Review Response Time measures how long each reviewer takes to give their first review on a pull request (PR) after they were asked. Span measures it once per reviewer per PR, so it shows reviewer responsiveness rather than how long a PR waits for its first review.
Why it matters
Slow first responses leave authors blocked and push work into context switching. This metric shows which reviewers or teams respond slowly, so you can rebalance review load or fix notification gaps. Don't optimize for speed alone: fast reviews that lack depth lead to more rework. Read it next to PR Review Cycles, Comments Received / PR, and PR Reviews / Week.
How it works
Start time. For each review, Span uses the first of these that exists: the earliest time someone requested this reviewer on the PR before the review; if nobody requested them, the latest ready-for-review event before the review; if neither exists, the PR's creation time.
End time. When the reviewer submitted the review, in any state: approved, changes requested, commented, or dismissed.
First review only. Span keeps each reviewer's earliest review on the PR and ignores later ones. A person with several Git accounts counts as one reviewer.
Weekends and time zone. If your organization excludes weekends, Span subtracts 24 hours for each Saturday and Sunday in the span, using your organization's time zone. A negative result becomes 0.
Placement. Each value lands in the period that contains the review's submission time.
Aggregation. Choose Trimmed Average (default), Median, 75th Percentile, 90th Percentile, or Max in Page settings. The Trimmed Average caps each value at 30 days before averaging. Percentiles and Max use raw values.
GitHub sends native reviews. On other platforms Span builds reviews from activity: on GitLab, an "approved" or "requested changes" note, or the first comment per person per PR per hour; on Azure DevOps, an approve, waiting-for-author, or reject vote; on Bitbucket Cloud, approvals, change requests, or the first published comment per person per PR per hour.
Reference ranges. Starting points, not targets:
Response time | Interpretation |
|---|---|
Under 2 hours | Excellent; authors are unblocked quickly |
2 to 8 hours | Good; typical for most teams |
8 to 24 hours | Moderate; may point to capacity limits or time zone gaps |
Over 24 hours | Slow; look for bottlenecks |
Setup
No setup is needed once a Git integration is connected. Find the metric in:
Insights → Productivity → Quality → Code review, with an All / Cross-Team toggle.
Team and person pages.
Custom dashboards.
Catalog → PR Reviews, which lists the individual reviews behind the number.
To make sure every reviewer counts once, add all of each person's GitHub or GitLab usernames on their profile in Settings → People Management. A person can have several.
Things to know
Worked example: Alice opens a PR Monday 09:00 and requests Bob and Carol. Bob reviews at 11:00. Carol reviews Tuesday 09:00. Bob reviews again Tuesday 15:00. Span records two values: 2 hours for Bob and 24 hours for Carol. Bob's second review doesn't count. The Trimmed Average for this PR's reviews is 13 hours.
Review-level, not PR-level: a PR with three reviewers gives three response times. Awaiting First Review in PR Lifecycle measures the PR's single wait from PR Opened to its first review or comment from anyone. Use that metric for PR-level wait and this one for reviewer responsiveness.
Weekends: with weekends excluded, a request Friday 17:00 answered Monday 09:00 shows 16 hours instead of 64. A request and review that both fall inside one weekend get no value.
Self-reviews don't count.
Bots and AI reviewers: a review counts only when the reviewer maps to a Span person, or to a coding agent your organization set up as a dev agent. Report pages show people only by default, so dev agent reviews stay out unless you include agent data. A bot's comment doesn't start or stop a human reviewer's clock.
Who counts: reviewers must be developer contributors. Reviews on ignored repositories or branches, and reviews by ignored Git usernames, don't count.
Draft PRs: if someone requests a reviewer while the PR is still a draft, the clock starts at that request, not when the PR leaves draft.
Re-requests: a request made after the reviewer's first review doesn't change the value.
Unmerged PRs count. The metric doesn't depend on merge.
Time zones: distributed teams naturally show longer response times, because elapsed time includes the reviewer's night. Compare against your own baseline before setting targets.
Why a PR shows no value: the only reviews came from the author, an unmapped bot, someone off the contributor list, or an ignored username; the PR is in an ignored repository or branch; the GitHub review is still pending; or the request and review both fell inside one excluded weekend.
Related articles
Using the Cross Team toggle in the Review Response Time Report
Need help?
Contact your Span account team or reach out to support@span.app.