Skip to content
DORA Metrics

DORA metrics that see the whole change, AI included

Measure deployment frequency, lead time, change failure rate and time to restore from the first local commit to production, and see how AI-assisted work changes each one.

Overview

Your four delivery numbers, on one screen

Each metric shows its current value, its trend over the last eight weeks and where it sits against the DORA benchmarks. Switch projects to compare them.

Deployment frequency
3.4 / day
Elite+18%, improving
Lead time for changes
19 h
Elite−22%, improving
Change failure rate
6.2%
High+0.8 pts, getting worse
Time to restore
52 min
Elite−31%, improving
The four metrics

What each metric tells you

Two measure speed and two measure stability. Together they show whether your team ships fast without breaking things.

  • Deployment frequency

    How often your team ships to production.

    How we measure it

    Counted from every production deployment, per project and for the whole team.

    Elite: On demand, several times a day

  • Lead time for changes

    How long a change takes to go from first commit to production.

    How we measure it

    Measured from the first local commit, not from when the pull request was opened, so the coding time counts too.

    Elite: Less than one day

  • Change failure rate

    The share of deployments that cause a failure in production.

    How we measure it

    Deployments followed by a rollback, hotfix or incident, divided by all deployments.

    Elite: Around 5% or lower

  • Time to restore

    How long it takes to recover when a deployment fails.

    How we measure it

    Time from the failed deployment to the fix or rollback that restored service.

    Elite: Less than one hour

01True lead time

Lead time that starts at the first commit

Most tools start the clock when a pull request is opened and miss the days of work before it. CloudByte AI starts at the first local commit and splits the time into coding, review and deployment, so you can see where changes really wait.

  • Starts at the first local commit, not the pull request
  • Split into coding, waiting for review, review and deploy
  • Shows the stage that slows each project down

Lead time for changes · All projects

19 h average
  • CodingFirst local commit to push9.5 h50%
  • Waiting for reviewPull request opened to first review4.2 h22%
  • ReviewFirst review to merge3.6 h19%
  • DeployMerge to production1.7 h9%

Coding takes the most time. A tool that starts at the pull request would miss these 9.5 hours entirely.

02AI attribution

See what AI does to your delivery

Every change is linked to the AI sessions that wrote it, so the four metrics can be split into AI-assisted and manual work. You see whether AI makes your team faster, and whether it costs you anything in review time or failures.

  • Each metric split by AI-assisted and manual changes
  • Linked to the sessions and prompts behind each change
  • Catch rising review time or failures early, per project

AI-assisted vs manual changes · Last 8 weeks

64% AI-assisted
Delivery metrics for AI-assisted changes compared with manual changes
MetricAI-assistedManual
Lead time for changesAI-assisted changes ship 44% faster15 h27 h
Coding timeMost of the gain happens before the push6.1 h15.8 h
Review timeLarger AI changes take longer to review5.4 h3.9 h
Change failure rateWorth a closer look on checkout-web6.9%5.1%
Where the numbers come from

Built from every step of the change

DORA metrics are only as good as the data behind them. CloudByte AI joins what happens on developer machines with what happens in your Git provider.

  • Local commits

    Captured by the agent on every developer machine, the true start of each change.

  • Remote commits and pull requests

    From GitHub, GitLab or Bitbucket, matched to the local commits behind them.

  • Reviews and merges

    When review starts, how long it takes and when each change is merged.

  • AI sessions

    The prompts and sessions behind each change, so every metric can be split by AI use.

  • Team and project level

    DORA metrics describe how a team delivers, so they are shown per project and per team, never as a score for one person.

  • Same definitions as the DORA research

    The four metrics follow the definitions from the DORA research program, so your numbers compare with industry benchmarks.

FAQ

DORA Metrics questions, answered

How the four metrics are measured and what they tell you.

Four measures of software delivery from the DORA research program: deployment frequency, lead time for changes, change failure rate and time to restore. Together they show how fast and how safely a team ships.

Most tools start the clock when a pull request is opened. CloudByte AI starts it at the first local commit, captured on the developer machine, so the coding time before the pull request is included.

Yes. Every change is linked to the AI sessions behind it, so each metric can be split into AI-assisted and manual work, per project and over time.

No. They describe how a team and its projects deliver, so they are shown per project and per team. Per-developer work is covered by Developer Insights.

They are the performance groups from the DORA research. Elite teams, for example, deploy on demand, have a lead time under one day and restore service in under an hour.

No. Local commits come from the agent already installed, and remote commits, pull requests and merges come from your Git provider once it is connected.

Know how fast and how safely your team ships.

Install the agent once per laptop, connect your Git provider and your DORA metrics start filling in.

  • Free for up to 5 developers
  • 10-minute setup
  • Your Anthropic key, your spend