DORA Metrics Cheatsheet

"Are we getting better at shipping software?" is a question most engineering teams answer with a feeling. DORA's four key metrics turn it into four numbers that can be pulled from systems you already have: version control, CI/CD and incident tracking.

The metrics come from the DORA (DevOps Research and Assessment) program, now part of Google Cloud, which has surveyed technology professionals every year for over a decade and published the results as the Accelerate State of DevOps report. The 2024 report, released in October 2024, is the tenth. It also contains some of the most discussed numbers of the year: AI adoption improves how developers feel and how their code looks, yet is associated with slightly worse delivery throughput and noticeably worse delivery stability.

This cheatsheet covers the definitions, the current benchmarks, how to compute the metrics yourself, how not to use them, and what the 2024 report says about AI and platform engineering.

1. The four keys (plus one)

DORA measures software delivery performance: how quickly and how safely a team gets changes of any kind (code or configuration) into production.

What changed recently

• Renamed metric. Older material calls the fourth key "time to restore service" or MTTR. DORA renamed it failed deployment recovery time in the 2023 report, narrowing it to recovery from failures caused by a deployment rather than any incident (an outage caused by a cloud provider is not a delivery failure).
• Two factors instead of one. Change failure rate never fit cleanly with the other three in DORA's statistical model. In 2024 DORA tested its long-standing hypothesis that change failure rate is a proxy for rework, added a survey question about unplanned, bug-fixing deployments, and confirmed the two are related. The 2024 report now describes delivery performance through two factors:
  • Throughput: change lead time, deployment frequency, failed deployment recovery time.
  • Stability: change failure rate, rework rate.
• Clusters still use the original four. For consistency with previous years, the 2024 performance clusters were computed on the four original metrics.

2. The 2024 performance clusters

DORA does not set the thresholds in advance. It runs a cluster analysis on survey responses and lets groups emerge, so the levels move from year to year.

How to read it:

• Speed and stability go together. The elite cluster is best on all four metrics at once. The idea that you must trade speed for safety does not hold at the extremes.
• Except in the middle. In 2024 the medium cluster had a lower change failure rate (10%) than the high cluster (20%). DORA chose to call the faster group "high" and noted this is one of the pitfalls of the labels: which is better depends on the service and its users.
• The gap is large. Compared with low performers, elite performers deploy 182 times more often, with 127 times faster lead times, 8 times lower change failure rate and 2,293 times faster recovery (as summarized by Octopus Deploy from the report).
• Improvement beats labels. The report's own words: the best teams are those that achieve elite improvement, not necessarily elite performance.

3. Measuring it yourself

You do not need a vendor to get started. You need three event streams and a few definitions you write down and keep stable.

Useful one-liners to get raw data from git:

# Commits shipped in a release (commit time, sha)
git log --format='%cI %h' v1.41.0..v1.42.0

# Deployment tags with dates, if you tag every production deploy
git for-each-ref --sort=creatordate --format='%(creatordate:iso8601) %(refname:short)' refs/tags/deploy-*

A minimal computation, given deployment records assembled from those sources:

from dataclasses import dataclass
from datetime import datetime, timedelta
from statistics import median


@dataclass
class Deployment:
    deployed_at: datetime
    commit_times: list[datetime]   # first-commit (or merge) time of each change shipped
    failed: bool = False           # caused a production failure (hotfix or rollback)
    recovered_at: datetime | None = None  # when the failure was resolved
    unplanned: bool = False        # shipped only to fix a user-facing bug (rework)


def dora_metrics(deploys: list[Deployment], days: int) -> dict:
    n = len(deploys)
    lead_times = [d.deployed_at - c for d in deploys for c in d.commit_times]
    failures = [d for d in deploys if d.failed]
    recoveries = [d.recovered_at - d.deployed_at for d in failures if d.recovered_at]
    return {
        "deploys_per_week": round(n / (days / 7), 1),
        "median_lead_time_h": round(median(lead_times) / timedelta(hours=1), 1),
        "change_failure_rate": round(len(failures) / n, 3),
        "median_recovery_h": round(median(recoveries) / timedelta(hours=1), 1) if recoveries else None,
        "rework_rate": round(sum(d.unplanned for d in deploys) / n, 3),
    }


t = datetime(2025, 4, 1, 9)
deploys = [
    Deployment(t, [t - timedelta(hours=20), t - timedelta(hours=6)]),
    Deployment(t + timedelta(days=1), [t + timedelta(hours=2)], failed=True,
               recovered_at=t + timedelta(days=1, minutes=45)),
    Deployment(t + timedelta(days=1, hours=1), [t + timedelta(days=1, minutes=30)], unplanned=True),
    Deployment(t + timedelta(days=3), [t + timedelta(days=2)]),
    Deployment(t + timedelta(days=8), [t + timedelta(days=4)]),
]
print(dora_metrics(deploys, days=14))
# {'deploys_per_week': 2.5, 'median_lead_time_h': 21.0, 'change_failure_rate': 0.2,
#  'median_recovery_h': 0.8, 'rework_rate': 0.2}

Practical rules:

• Use medians (and p90), not means. One six-week branch distorts an average lead time completely.
• Compute per service, trend over time. A weekly or monthly rolling window per service is what you act on.
• Low volume means noise. With 5 deployments a month, one failure moves change failure rate by 20 points. Use longer windows or show the counts next to the rate.
• Automate collection. Hand-filled spreadsheets drift. The open-source Four Keys project (archived in January 2024, still a useful reference design) and most CI/CD platforms show how to derive these from events.
• Ask too. DORA itself measures through surveys. A short quarterly survey ("How long does it take a change to reach production?") is a valid starting point and catches what logs miss.

4. Anti-patterns

5. SPACE in one paragraph

DORA measures the delivery pipeline. SPACE (Forsgren, Storey, Maddila, Zimmermann, Houck and Butler, ACM Queue, 2021) is a framework for developer productivity more broadly, with five dimensions: Satisfaction and well-being, Performance, Activity, Communication and collaboration, Efficiency and flow. Its main rule: no single metric captures productivity, so capture several metrics across at least three dimensions, mixing system data with perception data from surveys. DORA metrics fit inside SPACE (mostly Performance and Efficiency), and the combination prevents the classic mistake of measuring only Activity (commits, PRs, lines of code).

6. The 2024 AI findings

The 2024 report modeled what happens, on average, when AI adoption increases by 25%. These are associations from survey data with uncertainty intervals, not controlled experiments, but the direction matters.

Adoption and trust

A 25% increase in AI adoption is associated with...

The puzzle: historically, better documentation, code quality, faster reviews and less complexity all improve delivery. With AI, the process measures improved while delivery got worse. DORA's leading hypothesis is batch size: AI makes it easy to produce much more code in the same time, change lists grow, and DORA has shown for years that larger changes are slower and more prone to instability.

What to do with it:

• Keep changes small. Treat AI output like any other code: split it into small, reviewable PRs.
• Invest in tests before speed. The report's conclusion is that improving the development process does not automatically improve delivery without the basics: small batches and robust testing.
• Watch stability metrics when rolling out AI tools. Change failure rate and rework rate are your early warning.
• Faster review is not better review. The report itself warns that faster reviews and approvals could reflect over-reliance on AI.

7. The 2024 platform engineering findings

89% of respondents reported using an internal developer platform (defined broadly). Compared with not using one:

Key points from the report:

• Treat the platform as a product. User-centeredness (developers are the users), developer independence and a product mindset are what made platforms successful.
• Self-service matters. Being able to complete tasks without involving an enabling team was associated with higher productivity, and having a dedicated platform team with a gain in team-level productivity.
• Expect a J-curve. Productivity can dip while a platform is introduced before it improves.
• Watch instability. The combination of a platform and change instability was linked to higher burnout. One hypothesis: a platform makes it easy to push and quickly remediate changes, so bad changes get through and cause rework.

8. Other 2024 findings worth knowing

• User-centricity drives performance: organizations focused on the end user ship higher quality products, with more productive, more satisfied, less burned-out developers.
• Transformational leadership improves productivity, job satisfaction and team, product and organizational performance, and reduces burnout.
• Stable priorities matter: unstable organizational priorities led to meaningful decreases in productivity and substantial increases in burnout, even with strong leaders, good documentation and a user-centric approach.
• Cloud flexibility, not just cloud: moving to the cloud without adopting its flexibility can be worse than staying in the data center.

Why this matters

• Four numbers beat a feeling. Lead time, frequency, failure rate and recovery time show where delivery actually hurts.
• Throughput and stability are separate dials. The 2024 split into two factors, with rework rate, makes it explicit that you can improve one while breaking the other.
• AI is not a delivery strategy. The 2024 data shows individual gains do not reach production for free. Small batches and good tests are still the mechanism.
• Platforms need product thinking. An internal platform can raise productivity and still hurt stability if nobody watches the outcomes.
• Metrics are for learning. Used to compare teams or as targets, they get gamed. Used to find the next constraint, they compound.

Final Thoughts

DORA's metrics have survived a decade because they are simple, hard to argue with and connected to outcomes. The 2024 report adds two refinements worth adopting now: read throughput and stability as separate signals, and add rework rate next to change failure rate.

It also adds a timely warning. If your team is adopting AI coding tools this year, measure your delivery before and after, keep changes small, and watch change failure rate closely. The tools can make the work feel faster while the system ships slower. The only way to know which is happening is to measure it.

Sources

• DORA / Google Cloud, 2024 Accelerate State of DevOps Report (October 2024): metric definitions, rework rate, throughput and stability factors, 2024 performance clusters and shares (19/22/35/25%), AI findings (75.9% reliance, 39.2% little or no trust, +7.5% documentation quality, -1.5% throughput, -7.2% stability per 25% increase in AI adoption), platform engineering (89% usage, +8% individual productivity, +10% team performance, -8% throughput, -14% change stability), guidance not to compare teams. PDF.
• Nathen Harvey and Derek DeBellis, Google Cloud blog, Announcing the 2024 DORA report (October 23, 2024): summary of AI and platform engineering findings.
• DORA, 2024 DORA Report Infographic: 81% shifting resources to AI, 67% say AI improves their code, platform self-service findings.
• Octopus Deploy, The 2024 DevOps performance clusters (November 2024): 182x, 127x, 8x and 2,293x elite vs. low comparisons; medium and high change failure rate inversion.
• DORA, 2023 Accelerate State of DevOps Report (October 2023): the term "failed deployment recovery time" replaces the more generic "time-to-restore".
• Forsgren, Storey, Maddila, Zimmermann, Houck and Butler, The SPACE of Developer Productivity, ACM Queue 19(1) (2021): five dimensions, at least three recommended.
• Forsgren, Humble and Kim, Accelerate: The Science of Lean Software and DevOps (IT Revolution, 2018): origin of the four key metrics.
• DORA team, Four Keys (archived January 2024): open-source reference for deriving the metrics from event data.- Marilyn Strathern, "Improving ratings: audit in the British University system", European Review (1997): the common formulation of Goodhart's law.