# Review New to DORA? Start with [What is DORA?](/docs/engineering-delivery/what-is-dora), then come back here. The Review page shows how changes move through code review: how long they wait for a reviewer, how long they take to merge, how big they are, and how many were reviewed at all. Code review is when someone other than the author reads a change before it is merged, and for most teams it is also the biggest wait in getting a change to customers. This guide explains everything on the page, what each reading means and what to do about it. You find it under **Delivery**, as the **Review** tab. ## What the Review page shows At the top, the **Review update** sums up the period. When most of the time to merge is the wait for a first review, it says so and needs attention: "Most of the 20h to merge is spent waiting for a first review", adding "and large changes wait longest" when the largest changes take at least twice as long to merge as the smallest. Otherwise it says how long changes take from opening to merge and how that moved. With no code source connected it says "Connect your code to see how changes move through review. Nothing is estimated." Then come five tiles, each explained in its own section below: **Time to merge**, **Time to first review**, **Median change size**, **Merged without review** and **Review coverage**. Below them are the charts: - **Size decides speed and safety**: the changes merged in the last 30 days, by size band, with how many there were, their time to merge and how often they needed a fix. See [Change size](#change-size). - **Merge time by month**: the median hours from opening a change to merging it, with a split between **AI assisted** changes and **Other work**. See [Time to merge](#time-to-merge). - **First review, by team**: the median hours until a change gets its first review, per team, with the waiting changes behind each bar. A line underneath says how many of the changes merged without a review were AI assisted. - **How pull requests were reviewed**: how many were **Approved by a person**, **Passed by the review agents**, **Both** or **Neither**. Where a repository counts a person's review comment, the chart adds a bar **A person's review comment**, and where a repository counts green checks, a bar **Green checks**. Without review agents connected, there are no agent bars and the last bar is **Not approved**, or **Not reviewed** when comments or green checks count. See [Review coverage](#review-coverage). - **Why changes did not count as reviewed**: the reasons a merged change missed the review rule, largest first. See [Why a change did not count as reviewed](#why-a-change-did-not-count-as-reviewed). Every bar and row opens the changes behind it, by change and team, never by person. ## Why code review matters for delivery Code review is often where a change waits longest, so it has a large effect on how quickly work reaches customers. A change usually lives as a [pull request](/docs/engineering-delivery/glossary#pull-request): a proposal to add some code to the shared main line, which teammates read, comment on and approve before it is [merged](/docs/engineering-delivery/glossary#merge). Writing the code might take a morning. Then the change sits in a queue until a reviewer has time, goes back and forth a little, and is finally merged. Review is not part of the DORA metrics themselves, but it sits right inside one of them. [Change lead time](/docs/engineering-delivery/change-lead-time) runs from a change being committed to it running in production, and review happens in the middle of that. When teams break their lead time into steps, the wait for a first review is very often the largest one. [Where the time goes](/docs/engineering-delivery/speed#where-the-time-goes) on the Speed page shows this for your team. Google's engineering practices, a public guide to how Google runs code review, explains why speed matters: "we optimize for the speed at which a team of developers can produce a product together, as opposed to optimizing for the speed at which an individual developer can write code." Throughout this page we follow a fictional team of six who build an online booking app. Last month they merged 120 changes. ## Time to first review Time to first review is how long a change waits, from being opened, until a person other than its author first reviews it. ### Why it matters Waiting for a reviewer is often the largest single wait a change has, and it is the easiest one to shorten. Nothing about the code needs to change: the team just needs to pick up reviews sooner. While a change waits, its author usually starts something else, and then has to switch back when comments arrive. ### How to read it Look at the [median](/docs/engineering-delivery/glossary#median), the middle value, rather than the average: a single change that waited three weeks would drag an average up and hide what usually happens. In the booking team, the median change waits 26 hours for a first review. That is more than a working day for half of all changes. ### What good looks like Google's engineering practices give a clear figure: "One business day is the maximum time it should take to respond to a code review request (i.e., first thing the next morning)." They also say that "it's even more important for the individual responses to come quickly than it is for the whole process to happen rapidly." A quick first response keeps the author moving, even if the review then takes a few rounds. DORA publishes no figure for review time. ### How to improve it - **Agree a review window as a team.** For example, "every change gets a first review within one working day". This is the most common [working agreement](/docs/engineering-delivery/overview-and-focus#working-agreements). - **Review before starting something new.** Finishing a teammate's review usually helps the team more than opening another change of your own. - **Keep changes small.** People put off reviewing a huge change. A small one fits between other tasks. See [Change size](#change-size) below. - **Make waiting changes visible at standup.** A list of changes waiting longest is often enough to get them picked up. > **Tip:** Google also advises: "If you are in the middle of a focused task, such as writing code, don't interrupt yourself to do a code review." Fast review does not mean dropping everything. One way to manage both is to review at natural breaks in your day, such as after standup or after lunch. ### Common mistakes - Treating fast review as rubber-stamping. The goal is a quick first response, not a quick approval. - Measuring individual reviewers. Review speed is a property of how the team shares the work, not a score for a person. ### How Solidafy measures it The median hours from opening a change to its first review by a person other than its author, over changes merged in the period you choose. A bot or review app commenting first does not count. Changes opened by bots, such as Dependabot, are left out. The Review section also shows first review by team, and the retro nudge flags changes that have waited more than three days. ## Time to merge Time to merge is how long a change takes from being opened to being merged. ### Why it matters It is the wait for a first review plus the time spent in review, so it shows how long finished code sits before it can move on towards production. Most of that time is usually a queue, and queues slow everything behind them. ### How to read it Compare it with time to first review. In the booking team, the median change takes 40 hours to merge, and 26 of those hours are the wait for a first review. When the first wait is most of the total, the fix is picking reviews up sooner, not reviewing faster once started. Solidafy raises this as "Review wait" when the wait for a first review is more than half of the time to merge. ### What good looks like Google publishes no figure for time to merge, but its one business day maximum for responding to a review request is a useful anchor. No published source gives a target for the whole review, so compare with your own past. ### How to improve it - Agree a review window. - Keep changes small, because large changes need more rounds of review. - Make waiting changes visible at standup. - A working agreement such as "merged within 7 days of opening" catches changes that drift. ### Common mistakes Splitting one change into several dependent ones that all wait on each other. Small changes help only if each one can be reviewed and merged on its own. ### How Solidafy measures it The median hours from opening a change to merging it, over changes merged in the period you choose, with bots left out. The Review section also splits it by month into AI assisted changes and other work. ## Change size Change size is how many lines a change adds and removes. ### Why it matters Small changes are reviewed faster, deploy sooner and fail less often. It is the most reliable lever a team has, because it improves almost every other measure at once. DORA treats [working in small batches](https://dora.dev/capabilities/working-in-small-batches/) as a Core capability, and the [glossary](/docs/engineering-delivery/glossary#small-batches) explains the idea. Google's guide on small changes lists the benefits. Small changes are: - reviewed more quickly, - reviewed more thoroughly, - less likely to introduce bugs, - less wasted work if they are rejected, - easier to merge, - easier to design well, - less blocking on reviews, and - simpler to roll back. ### How to read it Look at the median, and then at how your changes spread across sizes. Solidafy groups changes into bands: | Band | Lines added and removed | | --- | --- | | XS | 0 to 49 | | S | 50 to 199 | | M | 200 to 399 | | L | 400 to 999 | | XL | 1000 or more | For each band the app shows how many changes there were, how long they took to merge and how often they needed a fix. In the booking team, the median change is 180 lines, but the 14 XL changes took four days to merge at the median and needed a fix twice as often as the rest. That table is usually the clearest argument for smaller changes a team will see. ### What good looks like Google's engineering practices: "100 lines is usually a reasonable size for a CL, and 1000 lines is usually too large", though it is up to the judgment of the reviewer. (A CL, or changelist, is Google's word for a change.) The guide adds that the number of files matters too: 200 lines in one file can be fine, while 200 lines spread over 50 files usually is not. ### How to improve it Split work into changes that each do one thing. Google's guide describes several ways: - **Stacking changes:** send one change for review and start the next one on top of it while you wait. - **Splitting by files:** separate parts that need different reviewers. - **Splitting horizontally:** build shared pieces, such as a new data layer, before the parts that use them. - **Splitting vertically:** break a feature into small, complete slices that each work end to end. A [feature flag](/docs/engineering-delivery/glossary#feature-flag) lets you merge unfinished work safely, switched off, instead of holding it back until the whole feature is done. > **Warning:** AI coding tools make it easy to produce very large changes in one go. DORA's working in small batches page warns that this creates cognitive overload for reviewers. The 2025 DORA research found that AI adoption still goes with more delivery instability, and DORA names working in small batches as one of the practices that counter it. See [AI and software delivery](/docs/engineering-delivery/ai). ### Common mistakes - Counting generated files, such as lock files, and then arguing about the number. Judge size by what a reviewer actually has to read. - Splitting a change in ways that leave the main line broken in between. ### How Solidafy measures it The median lines added and removed per change, over changes merged in the period you choose. A change whose tool does not report its size is left out, and so are changes opened by bots. ## Review coverage Review coverage is the share of merged changes that were reviewed before they were merged. ### Why it matters A review is the last check before a change reaches customers. Coverage says how much of the team's work got that check. See the [glossary](/docs/engineering-delivery/glossary#review-coverage) for a short definition. ### How to read it Higher is better, but the useful question is which changes were not reviewed and why. In the booking team, 112 of 120 merged changes were reviewed, which is 93%. What counts as a review depends on your policy. Many teams now use AI review agents alongside people. Solidafy counts a change as reviewed when a person approved it before the merge, or when the repository's review policy accepts something else and that held: - **Agent or person (default):** the review agents passed the exact commit that was merged. - **Green checks or a person:** every required check on the merged commit passed before the merge. With no check marked required, every check must pass. Checks are read from GitHub; on other code hosts only a person counts. - **A person must approve:** only a person's approval counts. Under any policy, a repository can also count a person's review comment: someone other than the author leaving a review comment or asking for changes before the merge counts, as an approval does. GitLab and Bitbucket record only approvals, so there only an approval counts. Some details matter: - A push after the agents passed means the merged commit was never checked, so it does not count. - An approval or review given only after the merge does not count, because it was not a check before the change went in. ### What good looks like No published source gives a figure. Compare with your own past, and look at every unreviewed change rather than chasing a percentage. ### How to improve it - Require a review on the main branch in your code host's settings. - Decide per repository whether a review agent's pass, green checks or a person's review comment count as a review. - Look at the reasons changes did not count. Solidafy lists them, for example "approved only after the merge" or "no agent ran before the merge". ### How Solidafy measures it The share of pull requests merged in the period you choose that were reviewed before the merge, counting a review agent, or every required check on the merged commit passing before the merge, where the repository's review policy allows it. Where a repository counts a person's comment, a person other than the author leaving a review comment or asking for changes before the merge counts too. Bots are left out. ### Why a change did not count as reviewed Each merged change that missed the review rule gets one reason. Here is what each means and how to fix it. | Reason in the app | What happened | What to do | | --- | --- | --- | | "Pushed after the agent passed" | The review agents passed the change, then someone pushed another commit before merging, so the commit that merged was never checked. A line under the chart counts these: "Only a pass on the commit that merged counts." | Let the agents run again after the last push before merging, or ask a person to approve the final version. | | "The agents did not pass the merged commit" | The review agents ran on the merged commit but did not pass it. | Look at what the agents flagged, and fix it or get a person's approval before merging. | | "No agent ran before the merge" | The change was merged before the review agents had a chance to run. | Wait for the agents' result before merging; making their check required on the main branch prevents this. | | "Review agents not connected for the code host" | The repository's code host has no review agents connected, so only a person's approval could count. | Connect the review agents for that code host, or make sure a person approves. | | "Needs a person, and none approved" | The repository's policy says a person must approve, and nobody did. | Get a person's approval before merging; require it on the main branch. | | "Approved only after the merge" | Someone approved, but only after the change was already merged, so it was not a check before the change went in. | Approve before merging. If it happens often, require a review before merge in your code host. | | "A check did not pass on the merged commit" | The repository counts green checks, and a check on the commit that merged failed, was cancelled or was run again after the merge. | Fix the failing check before merging, or get a person's approval. | | "A check was still running at the merge" | The repository counts green checks, and a check had not finished when the change merged. | Wait for every check to finish before merging; requiring the checks on the main branch prevents this. | | "No check had run on the merged commit by the merge" | The repository counts green checks, but no check had started on the commit that merged before it was merged. | Make sure your checks run on every push, and wait for them before merging. | | "Checks not read for this change" | The repository counts green checks, but no check was read for the change, for example because its code host does not report checks to Solidafy. | Get a person's approval. Checks are read from GitHub only. On GitHub, its checks may simply not have been pulled in yet. | | "A person reviewed only after the merge" | The repository counts a person's review comment, and the first review by someone other than the author came after the merge. | Review before merging. | | "Needs a person to review, and none did" | The repository says a person must approve and also counts a review comment, and nobody other than the author reviewed it. | Get a person to review before merging; require a review on the main branch. | > **Note:** What counts is set per repository under **Review policy** in Settings: "Agent or person (default)", "Green checks or a person" or "A person must approve", and whether a person's review comment counts there too. See [Setting it up](/docs/engineering-delivery/setup#review-policy). ## Changes merged without review Changes merged without review is the share of merged changes that nobody reviewed before they went in. ### Why it matters A change nobody else read is a change nobody else checked. The risk grows with AI written code: the 2025 DORA report found that 30% of respondents had little or no trust in code generated by AI, which makes a second pair of eyes more important, not less. ### How to read it It is the other side of review coverage, but worth watching on its own because it often hides a pattern: emergency fixes pushed at night, one repository without branch protection, or a habit of self-merging small changes. In the booking team, 8 of 120 changes were merged without review, and 5 of those were AI assisted. ### What good looks like No published source gives a figure. Compare with your own past. Solidafy raises "Unreviewed merges" as worth a look when the share goes up, and marks it as needing attention once it reaches 10% or more. ### How to improve it - Require a review on the main branch. - Make the exceptions visible at the retro, so the team decides together when skipping review is acceptable. ### How Solidafy measures it The share of changes merged in the period you choose with no review before the merge. Bots are left out, and the Review section shows how many of the unreviewed changes were AI assisted. ## Merge rate Merge rate is the share of pull requests that were merged, of those that have since been merged or closed. The Review page shows it under the tiles, for example "merge rate: 45 of the 50 pull requests opened in the last 30 days and since merged or closed were merged", with the rate before next to it. It is also a column in [Teams side by side](/docs/engineering-delivery/team-health#teams-side-by-side). ### Why it matters Pull requests closed without a merge are work that did not ship. A falling rate can mean unclear requirements, or work started and dropped. ### What good looks like No published source gives a figure, so compare it with your own past. ### How to improve it Look at the pull requests closed without a merge, and why they were closed. ### How Solidafy measures it Of the pull requests opened in the period you chose that have since been merged or closed, the share merged. One still open has not settled, so it is left out until it does. Drafts count. Changes opened by bots, such as Dependabot, are left out. ## Review and AI AI tools help people write code faster, which moves the bottleneck to review. DORA's 2026 report on the return on investment of AI calls this the verification tax: the extra time spent reviewing and testing AI generated code, both because people do not fully trust it and because there is simply more of it. Faster writing only turns into faster delivery if review keeps up. The practices on this page, small changes and quick first reviews, are exactly what keeps review from becoming the constraint. The [AI and software delivery](/docs/engineering-delivery/ai) guide covers this in more depth. ## Questions the app raises ### The update says most of the time to merge is waiting for a first review. What do we do? It means the queue before review, not the review itself, is what slows changes down. Changes sit finished while nobody has started reading them. Pick reviews up sooner: agree a review window as a team, review before starting something new, and make waiting changes visible at standup. Open **First review, by team** to see which team's changes wait longest and the changes behind each bar. To keep it in view, set "The queue before code review" as your focus and add a "First review within 24 hours" working agreement; see [Overview, focus and working agreements](/docs/engineering-delivery/overview-and-focus). ### It adds "large changes wait longest". Does size really matter that much? Yes. It means your largest changes take at least twice as long to merge as your smallest. Large changes are harder to review, so people put them off. Open **Size decides speed and safety** to see the gap and how often each size needed a fix, then open the L and XL rows to see which changes could have been split. A "Changes under 400 lines" working agreement helps the habit stick. ### Review coverage dropped. Where do I look? Open **Why changes did not count as reviewed**. The largest bar tells you the main cause, and each row opens its changes. Most drops come from one habit, such as pushing a last fix after the agents passed, or one repository without a review requirement. ### AI assisted changes merge faster than the rest. Is that good? On its own, it is neither. Check that they were reviewed as carefully: the line under **First review, by team** says how many unreviewed merges were AI assisted, and the [AI page](/docs/engineering-delivery/ai#ai-assisted-changes) compares how often AI assisted changes needed a fix. Faster merging with more fixes is a warning sign, not a win. ### A tile says it is not measured. Why? Review measures need a connected code host. Change size needs a host that reports lines added and removed, and review coverage reads review agents only where they are connected. See [Setting it up](/docs/engineering-delivery/setup#why-does-a-tile-say-it-is-not-measured). ## Learn more Official sources: - [Google engineering practices: speed of code reviews](https://google.github.io/eng-practices/review/reviewer/speed.html) - [Google engineering practices: small changes](https://google.github.io/eng-practices/review/developer/small-cls.html) - [DORA capability: working in small batches](https://dora.dev/capabilities/working-in-small-batches/) - [DORA capability: streamlining change approval](https://dora.dev/capabilities/streamlining-change-approval/) - [State of AI-assisted Software Development 2025](https://dora.dev/research/2025/dora-report/) Related Solidafy guides: - [Change lead time](/docs/engineering-delivery/change-lead-time) - [Improving software delivery](/docs/engineering-delivery/overview-and-focus) - [Flow of work](/docs/engineering-delivery/flow) - [Change fail rate](/docs/engineering-delivery/change-fail-rate) - [AI and software delivery](/docs/engineering-delivery/ai) - [Glossary](/docs/engineering-delivery/glossary)