Change Lead Time
Note: This metric is only shown at a team level, not an individual level.
What it is: This is DORA's Change Lead Time (previously called Lead Time in the app), 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 (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 book. Note that this is closely related to Cycle Time; we measure Change Lead Time since that's recommended by DORA. See here 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 a successful attempt of deployment to production for that PR, or to PR merged if there is no deployment data.
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).
What good looks like
The latest DORA research (from 2025) shows that the top 15% of responses have a Change Lead Time of less than 24 hours.
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 and Deploy Time.
These exclusions apply to Coding Time, Review Wait Time, and Editing Time :
Our focus is on PRs that the team collaborated on, so we exclude bot merges and selfie-merges (PRs merged by the PR author, with no comments or reviews by other collaborators).
If you like, you can choose to exclude weekend hours from these calculation; simply toggle on “Exclude Weekend Hours”.
For just Change Lead Time and Coding Time, please note:
When you first join Multitudes, your historical data (the first 6 weeks) will show a lower time metric if your company does a lot of rebasing. This is because we can’t get original commits from the historical data in GitHub, so the rebased commit is taken as the first commit.
Once you integrate, we get events data from GitHub. This means we will get the original commits that are pushed to GitHub, even if your teams rebase or squash the commits later. Therefore, you might notice that your metrics are higher after the time that you onboard onto Multitudes, compared to your historical data.
If you rebase your commits before pushing the branch to GitHub for the first time, GitHub notifies us of the rebase time rather than when the commits were originally made. In order to provide the most accurate measure of
Coding Time, we therefore encourage you to push commits to GitHub as they are made, even if the intent is to rebase or squash these commits before opening a PR or requesting a review.
For Review Wait Time, please note:
The counting for the
Review Wait Timestarts when a review is first requested. If a review was never requested (i.e. when someone provides a review without being asked to review), we fall back to counting from the time the PR was first opened or when it was first moved to "Ready for review" if it was initially a draft PR.
For just the separate Deploy Time line chart:
If you’re using the GitHub Actions integration…
We do include selfie PRs (non-collaborative PRs) in this metric.
This is because we want to provide the most comprehensive view of how long your deployment pipeline takes, which means incorporating all relevant data.
Whether a deploy is of a collaborative PR or a selfie PR, this should not normally influence how long the deploy takes, therefore selfie PRs are a relevant segment of your team’s data on how long things take to deploy.
If you're using the Deployments API, we only look at what you POST, so you can decide how you want to treat selfie PRs
For
Change Lead Timewe intentionally include all merged PRs, even if they are not yet deployed (or if deployment metrics aren’t available), 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 broken up into its four components, Coding Time, Review Wait Time, Editing Time, and Deploy Time. Where these start and end can depend on the events in each PR's life cycle. Here is a typical PR timeline. Click the dropdown below it for more scenarios.
More PR life cycles scenarios
Last updated
Was this helpful?