> For the complete documentation index, see [llms.txt](https://docs.multitudes.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.multitudes.com/metrics-and-definitions/process-metrics/flow-of-work/review-wait-time.md).

# Review Wait Time

![Review Wait Time graph](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FTF2vUprHASCnPawZdcJu%2FReview%20Wait%20Time.png?alt=media\&token=a29603cc-3da8-49cc-be46-06df05452067)

**What it is:** This shows how long people wait to get feedback on their PRs.

**Why it matters:** This is one possible bottleneck for `Change Lead Time`. When people have to wait longer for feedback, it can mess up their workflow. They’re more likely to start a new piece of work while waiting for feedback. When they get that feedback, they have to context-switch, making it harder for them to remember what they did. This often results in longer times taken for each of the tasks to be completed (for example, [one study showed](http://blog.ninlabs.com/2013/01/programmer-interrupted/) that it takes 10-15 minutes to get back into context).

Moreover, there’s bias in how long different groups of people have to wait for feedback. For example, [this research](http://www.erinhengel.com/research/publishing_female.pdf) showed that women had to wait longer than men for feedback. This is why we *do* show this metric at the individual level — so that you can make sure that everyone is receiving feedback in a timely manner.

**How we calculate it:** We measure the **number of hours from the first human review request to the first human response** on a PR. A human review request is a request to a person or a team, not a bot. A human response is a submitted review (approved, changes requested, or commented) from someone who is neither the PR author nor a bot. Standalone PR comments that aren’t part of a review don’t count. To be clear on some nuances:

* If a review was requested but nobody responded before the merge, `Review Wait Time` runs from the request to the merge.
* If no human review was ever requested, `Review Wait Time` is `null`. Any time before the first response counts as `Coding Time`.
* A review request made after the first response is ignored, so there’s no wait.
* Responses at or after the merge don’t count.
* Whether a PR is in draft state doesn’t affect `Review Wait Time`.
* See [here](/metrics-and-definitions/process-metrics/flow-of-work/change-lead-time.md#additional-calculation-notes-for-change-lead-time-and-subsets) for some additional calculation notes that apply from `Change Lead Time`.

{% hint style="success" %}
**What good looks like**

We recommend that `Review Wait Time` be under **4 hours**.

This threshold is based on an internal analysis conducted by Multitudes in Q4 2026 across 40,000 PRs from a diverse range of customers and comparing against the SPACE and DORA research. We've intentionally focused on a recent subset of data because practices are changing so quickly now with AI.
{% endhint %}