DORA Four Keys — Implementation

Implementing DORA 4 Keys in practice — measuring deployment frequency, lead time, change failure rate, and MTTR using real tooling, data pipelines, and dashboards.

Overview

Measuring delivery performance

The DORA Four Keys are the most widely validated metrics for software delivery performance. The DevOps Research and Assessment team (now at Google Cloud) identified them and validated them across 7+ years of the State of DevOps Report. They predict organizational performance and team well-being.

The four metrics and how to instrument them

Deployment Frequency — How often code is deployed to production — Counting successful pipeline runs tagged environment=production, grouped by day or week
Lead Time for Changes — Time from a commit being merged to that commit running in production — Tracking commit hashes in each deployment: deployment_timestamp minus commit_timestamp for each included commit
Change Failure Rate (CFR) — Share of deployments that cause a production incident, rollback or service degradation — Linking incidents and rollbacks to the triggering deployment: CFR = incidents_linked_to_deployments / total_deployments
Mean Time to Restore (MTTR) — How long it takes to restore service after a production failure — Exporting from PagerDuty or OpsGenie: MTTR = mean(resolved_at minus triggered_at) for all production incidents

Benchmarks

Deployment Frequency — Multiple times per day — Once per day to once per week — Once per week to once per month — Less than once per month
Lead Time for Changes — Less than one hour — One day to one week
Change Failure Rate — 0-15% — 16-30%
MTTR — Less than one hour — Less than one day

Linking incidents to deployments

> [!IMPORTANT] CFR is only as accurate as the link between incidents and the deployment that caused them: record the deployment on every incident.

Tooling options

DORA Quick Check at dora.dev — Free self-assessment survey
Four Keys open-source project (Google) — BigQuery plus a Looker Studio dashboard pulling from GitHub or GitLab and PagerDuty
Sleuth, LinearB, Faros AI — Commercial platforms with automatic integration
Custom — GitHub Actions plus CloudWatch or Datadog metrics with a custom dashboard

> [!NOTE] Reliability (meeting SLOs) was added to the DORA model in 2021; since the 2023 report it is tracked as a separate operational outcome alongside the four keys.

Key concepts

Deployment Frequency: How often code is successfully released to production. The primary velocity metric. Elite performers deploy multiple times per day. Measured by counting successful production deployment events in the CI/CD pipeline.
Lead Time for Changes: Time from code commit to that commit running in production. Measures the speed of the full delivery pipeline. Calculate as deployment_timestamp minus commit_timestamp for all commits in each release.
Change Failure Rate (CFR): Percentage of deployments causing a production incident, rollback, or hotfix. The quality and stability counter-balance to deployment frequency. Link incidents and rollbacks to the triggering deployment to calculate.
Mean Time to Restore (MTTR): Average time from production incident detected to service restored. Measures team responsiveness and system recoverability. Export from incident management tools as resolved_at minus triggered_at.
DORA Performance Clusters: DORA research classifies teams into Elite, High, Medium, and Low clusters based on the four key values. Elite teams have far more frequent deployments, faster lead time, lower CFR, and faster MTTR than Low performers.
DORA 5th Key: Reliability: Added in 2023. Measures whether teams are meeting their user-facing SLOs. Operationalized as the percentage of time a service meets its SLO. Captures operational stability alongside velocity.

When to use it

Setting up engineering metrics programs for DevOps teams
Interview questions about measuring software delivery performance
Demonstrating data-driven DevOps improvement to engineering leadership
Benchmarking team performance against DORA elite or high or medium or low clusters
Identifying bottlenecks in the software delivery pipeline