> 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/change-lead-time.md).

# Change Lead Time

{% hint style="info" %}
⭐️ This metric is one of the [4 Key Metrics published by Google's DevOps Research and Assessment (DORA)](https://dora.dev/guides/dora-metrics-four-keys/) team.

You can see all 4 key DORA metrics on the [DORA Metrics page](https://app.multitudes.co/DORA) of the Multitudes app.
{% endhint %}

![Change Lead Time graph](https://cdn.prod.website-files.com/610c8a14b4df1ae46b1a13a3/6739fb3d6f5f42c0839a9dbc_flow-of-work-leadtime.png)

***‍*****What it is:** This is DORA's `Change Lead Time`, a metric that shows how long it takes the team to write code, request and give feedback, make revisions, merge the PR, and then deploy into production. It’s an indicator of how long it takes to deliver value to customers.**‍**

**Why it matters:** `Change Lead Time` is one of the top four indicators of software team performance, according to [Google’s DORA research](https://cloud.google.com/devops/) (the DevOps Research and Assessment research). Their research shows that a faster `Change Lead Time` is correlated with better business outcomes. Specifically, teams with a faster `Change Lead Time` do work that is better, more stable, and more secure. If you want to dive deeper into this, check out the [Accelerate](https://itrevolution.com/book/accelerate/) book. Note that this is closely related to `Cycle Time`; we measure `Change Lead Time` since that's recommended by DORA. [See here](https://www.multitudes.com/blog/lead-time-vs-cycle-time) for more about the differences between `Change Lead Time`, `Cycle Time`, and `Lead Time`.

**How we calculate it:** To calculate `Change Lead Time`, we measure the **number of hours from the first new commit** on a pull request’s (PR’s) branch **to the first successful deployment to production that includes the PR’s merge commit**, or **to the PR being merged** if there is no deployment data.‍

{% hint style="info" %}
This means some of the PRs included in this chart will not yet be deployed. This is so that you can get insights for all repositories, even ones that don’t have workflows configured. You can get a breakdown of how long PRs are taking to merge vs. deploy with the Change Lead Time subsets chart or the specific line charts (like [this one for deploy time)](/metrics-and-definitions/process-metrics/flow-of-work.md#deploy-time).
{% endhint %}

{% hint style="info" %}
Because the end point for Change Lead Time is a merge (or a successful attempt to deploy to production if available), the metrics will not include PRs that were closed (i.e not merged)
{% endhint %}

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

Our benchmarks show that the top companies have a Change Lead Time of **20 hours or less**. Note that this is faster than the last DORA benchmark ([from 2025](https://dora.dev/research/2025/)), which showed that the top 15% of code changes have a `Change Lead Time` of less than 24 hours.

The Multitudes benchmark was run 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 %}

### **Additional calculation notes for Change Lead Time & subsets**

Here are a few additional notes that affect the calculations for `Change Lead Time` and/or its components, `Coding Time`, `Review Wait Time`, `Editing Time`, `Merge Wait Time` and `Deploy Time`.

These apply to `Change Lead Time` and all of its subsets:

* Our focus is on PRs that the team collaborated on, so you can use the **Collaborative PRs / All PRs** toggle to choose which PRs are included. When **Collaborative PRs** is selected, we exclude selfie PRs (PRs with no reviews, comments, or merges from human contributors other than the PR author). When **All PRs** is selected, selfie PRs are included.
* If you like, you can choose to exclude weekend hours from these calculations; simply toggle on “Exclude Weekend Hours”. Weekend hours follow the PR author’s working days.

For just `Change Lead Time` and `Coding Time`, please note:

* For the most accurate `Change Lead Time`, open a PR (even a draft) right after your first commit, then push subsequent commits as you make them. This lets us associate each commit with the PR, so any later squash or rebase won't affect `Change Lead Time`.
* If commits are squashed before a PR is opened, the original timestamps are generally lost. While there are approaches that may preserve the original timestamp (such as locally squashing via `git rebase -i` ), treat pre-PR squashing as timestamp-destructive by default.
* This means that for both the historical data ingestion process (the first 6 weeks) and the ongoing ingestion process, commits squashed before the PR is opened will show an artificially low `Coding Time`. By definition, `Coding Time` starts at the first commit. Because we lose the true first commit timestamp on squashed commits, we have to use the timestamp of the squashed commit, which is later – that's what makes `Coding Time` artificially low. This can't be corrected retroactively for historical data.

For `Review Wait Time`, please note:

* `Review Wait Time` only starts when a *human* requests a review. If no review was requested, there is no `Review Wait Time`; [see the scenarios below](#more-pr-life-cycle-scenarios).

For the separate `Deploy Time` line chart:

* `Deploy Time` follows the **Collaborative PRs / All PRs** toggle, just like `Change Lead Time` and its other subsets.
* If you’re using the [GitHub Actions integration](/integrations/github-actions.md), we match each deploy to a PR using the PR’s merge commit.
* If you're using the [Deployments API](/integrations/deployments-api.md), we only look at what you POST, and we match the commitSha you send to the PR’s merge commit.
* For `Change Lead Time` we intentionally include all merged PRs, even if they are not yet deployed (or if [deployment metrics aren’t available](/metrics-and-definitions/deployment-metrics.md)), so that you are getting insights across all repositories, even if some of them are not set up with GitHub Actions deploy pipelines or the Deployments API.

### **How Change Lead Time is broken into its subsets**

`Change Lead Time` is split into five consecutive parts: `Coding Time`, `Review Wait Time`, `Editing Time`, `Merge Wait Time`, and `Deploy Time`. Each part starts where the previous one ends, so for any single PR the parts always add up to its `Change Lead Time`. If an event is missing, the part that depends on it is empty (`null`).

| Part               | Starts                                                   | Ends                                                                                          |
| ------------------ | -------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| `Coding Time`      | First commit                                             | When the next part starts (usually the first human review request)                            |
| `Review Wait Time` | First human review request                               | First human response (from someone who's not the PR author), or the merge if nobody responded |
| `Editing Time`     | First human response                                     | Last commit, only if it comes after the first human response                                  |
| `Merge Wait Time`  | Last commit, or the first human response if that’s later | Merge                                                                                         |
| `Deploy Time`      | Merge                                                    | Deploy                                                                                        |

**What counts:**

* Only human review requests and reviews count, not bot ones – because bot ones happen quickly. Review requests sent to a team count as a human review request.
* A *response* is a submitted review (approved, changes requested, or commented). Standalone PR comments that aren’t part of a review don’t count.
* A review request made after the first response is ignored.
* A response at or after the merge doesn’t count.
* A deploy recorded before the merge is ignored. `Change Lead Time` then ends at the merge.
* Whether a PR is in draft state doesn’t affect any part.

**PRs that haven’t merged yet:** `Change Lead Time` is only calculated once a PR is merged. A part appears as soon as its end point has happened; from that point, it won't change. For example, an open PR with a review request already has `Coding Time`. While a PR is open, nothing ends at the last commit, because more commits can still land. On a closed PR the last commit is final, so it gets `Coding Time` and `Editing Time` but no `Merge Wait Time` or `Change Lead Time`. If a PR is reopened, its parts reset until they settle again.

Here is a typical PR timeline. Use the tabs below for more scenarios.

![Timeline of a PR with every event: first commit, review request, first human response, last commit, merge, and deploy, showing all five parts of Change Lead Time.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FSHMmuN8e4TQJry7rR2Ru%2F1-every-event.svg?alt=media)

{% hint style="info" %}
For any one PR, the parts add up exactly to its `Change Lead Time`. The Change Lead Time by subset chart in the app shows the percentile value (for example, P50, the median) of each component separately, so the percentiles shown there may not add up to the overall `Change Lead Time` percentile in the Change Lead Time line chart.
{% endhint %}

## More PR life cycle scenarios

### Reviews and commits in different orders

{% tabs %}
{% tab title="Last commit before first response" %}
![Timeline of a PR where the last commit happens after the review request but before the first human response.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2F5e2b9a9reNduRl5Yzbbw%2F2-last-commit-during-review-wait.svg?alt=media)

The author pushes a final commit after requesting review but before anyone responds. Because the last commit comes before the first human response, there’s no `Editing Time`. `Review Wait Time` ends at the response, and `Merge Wait Time` runs from the response to the merge.
{% endtab %}

{% tab title="No commits after approval" %}
![Timeline of a PR that is approved and merged with no further commits.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FPcjo6e7UKprjwaq2DaNv%2F11-approved-no-further-commits.svg?alt=media)

A reviewer approves and the author makes no more commits. There’s no `Editing Time`, so `Merge Wait Time` runs from the approval to the merge.
{% endtab %}

{% tab title="No review request" %}
![Timeline of a PR where a reviewer responds without a review having been requested.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FwO7a4w839MdIfgL2fWvr%2F3-no-review-request.svg?alt=media)

A reviewer responds without having been asked. With no request there’s no `Review Wait Time`, so `Coding Time` runs until the response and `Editing Time` starts there.
{% endtab %}

{% tab title="Response before review request" %}
![Timeline of a PR where a reviewer responds before a review is requested.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FZ3vGE3yVLC2zEYGtHit9%2F6-response-before-request.svg?alt=media)

A reviewer responds first, and a review is requested afterward. The late request is ignored, so there’s no `Review Wait Time`. `Coding Time` ends at the response, and `Editing Time` starts there.
{% endtab %}
{% endtabs %}

### Missing events

{% tabs %}
{% tab title="No review request or response" %}
![Timeline of a PR with no review request and no human response.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FfOQkili9zU8lXwJ0canu%2F4-no-request-or-response.svg?alt=media)

Nobody is asked to review and nobody responds. `Coding Time` runs to the last commit, then `Merge Wait Time` runs to the merge. There’s no `Review Wait Time` or `Editing Time`.
{% endtab %}

{% tab title="Review request but no response" %}
![Timeline of a PR where a review is requested but nobody responds before the merge.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FAEyzjiRCwxx4SoqbIgxl%2F5-request-but-no-response.svg?alt=media)

A review is requested, but nobody responds before the PR is merged. `Review Wait Time` runs from the request to the merge. There’s no `Editing Time` or `Merge Wait Time`.
{% endtab %}

{% tab title="Merged, no deploy" %}
![Timeline of a PR that is merged but has no deployment recorded.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FipdMwg7cHZOvRRCXpZkb%2F9-merged-no-deploy.svg?alt=media)

No deployment is recorded for the PR (for example, the repository has no deploy pipeline connected). `Deploy Time` is empty, and `Change Lead Time` ends at the merge.
{% endtab %}

{% tab title="PR opened before first commit" %}
![Timeline of a PR that was opened before the earliest commit we can find.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FxoYNv9TaYI1R15Wdmkdv%2F12-pr-opened-before-first-commit.svg?alt=media)

Occasionally, because of a rebase, the PR’s original first commit no longer exists in the history, so the earliest commit we can find is later than the PR’s opening. In that case `Coding Time` starts when the PR was opened.
{% endtab %}
{% endtabs %}

### Events that are ignored

{% tabs %}
{% tab title="Bot activity" %}
![Timeline of a PR where a bot responds before any human.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FeDVlMvH5wc1IkOMAPfL8%2F10-bot-responded-first.svg?alt=media)

Bots that are requested as reviewers, or that review the PR, don’t count. `Review Wait Time` runs from the first request to a person or team until the first human response.
{% endtab %}

{% tab title="Late review" %}
![Timeline of a PR where a review is submitted after the merge and is ignored.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FGphsoAls4NTDjkuwkiWQ%2F13-late-review-ignored.svg?alt=media)

A review submitted at or after the merge doesn’t count as a response. The PR is treated as if that review never happened.
{% endtab %}

{% tab title="Draft PR" %}
![Timeline of a PR that starts as a draft, showing that draft status has no effect on the parts.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FYqUqfCu6z8fDrpCKeFbB%2F14-draft-pr-no-effect.svg?alt=media)

A PR that starts as a draft and is marked “ready for review” later is treated like any other PR. Draft status doesn’t change where any part starts or ends.
{% endtab %}
{% endtabs %}

### PRs that haven’t merged

{% tabs %}
{% tab title="Open PR, review requested" %}
![Timeline of an open PR that has a review request but no response yet.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FeXZX1KYSiNgJBtQIR0fT%2F7-open-pr-review-requested.svg?alt=media)

The request has happened and can’t change, so `Coding Time` already ends there. `Review Wait Time` and the later parts stay empty until someone responds or the PR merges, and there’s no `Change Lead Time` until it’s merged.
{% endtab %}

{% tab title="Open PR with a response" %}
![Timeline of an open PR that has a human response but no review request.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FgSXCq2EUqbCJQOoN8gAp%2F15-open-pr-first-response-only.svg?alt=media)

A reviewer has responded and the PR is still open. `Coding Time` ends at the response. Nothing ends at the last commit while a PR is open, so the remaining parts are empty.
{% endtab %}

{% tab title="Closed without merging" %}
![Timeline of a PR that is closed without being merged.](https://3759751588-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F1eOL1LoKX0USQQUCSepS%2Fuploads%2FJbvt6Sc6byvOdm4LpZlj%2F8-closed-without-merging.svg?alt=media)

The last commit on a closed PR is final, so the PR gets `Coding Time` and, if there was a response, `Editing Time`. There’s no `Merge Wait Time` and no `Change Lead Time`, because there was no merge.
{% endtab %}
{% endtabs %}