DORA Metrics in Plain English: Deployment Frequency, Lead Time, and More
Understand the four DORA metrics in clear English — what they mean, how to discuss them in team meetings, and vocabulary for engineering performance conversations.
DORA metrics are the four engineering performance indicators developed by the DevOps Research and Assessment team at Google. They are now the standard language for discussing software delivery performance in English-speaking engineering organisations. This guide explains each metric clearly and shows you how to use them in team meetings and written reports.
The Four DORA Metrics
1. Deployment Frequency
What it measures: How often your team successfully deploys to production.
Categories:
- Elite: Multiple times per day
- High: Once per day to once per week
- Medium: Once per week to once per month
- Low: Less than once per month
In plain English: Deployment frequency tells you how quickly value reaches users. High-frequency deployment is associated with lower risk per deployment (smaller changes) and faster feedback loops.
Team meeting phrases:
- “We’re currently deploying twice a week — our target is to reach daily deployments by Q3.”
- “Deployment frequency dropped last quarter because we were mid-migration — it should recover once the new pipeline is stable.”
2. Lead Time for Changes
What it measures: The time from a code commit to that code running in production.
Also expressed as: commit-to-deploy time, cycle time
In plain English: Lead time reflects how fast your engineering process is. Long lead times usually indicate bottlenecks in testing, review, or deployment pipelines.
Team meeting phrases:
- “Our median lead time is currently four days — the main bottleneck is the integration test suite, which takes three hours to run.”
- “Reducing lead time is a priority this half because it directly affects how quickly we can respond to production issues.”
3. Change Failure Rate
What it measures: The percentage of deployments that cause a production incident and require a hotfix, rollback, or patch.
Formula: (Number of failed deployments ÷ Total deployments) × 100
In plain English: This metric tells you how often your deployments go wrong. Elite teams have a change failure rate of 0–15%. A high change failure rate usually signals insufficient testing, review, or staging environments.
Team meeting phrases:
- “Our change failure rate last month was 22%, which is above our target. We’re reviewing the pre-deployment checklist to identify the gaps.”
- “The spike in change failure rate coincided with the removal of integration tests — restoring them is a priority.”
4. Mean Time to Recovery (MTTR)
What it measures: The average time it takes to restore service after a production incident.
Also expressed as: mean time to restore, recovery time
In plain English: MTTR measures your team’s ability to respond and recover when things go wrong. Elite teams recover in under one hour. High MTTR often indicates poor observability, complex rollback procedures, or unclear on-call processes.
Team meeting phrases:
- “Our MTTR for P1 incidents is currently 45 minutes — we want to bring that below 30 minutes by improving our runbooks.”
- “We need to invest in better observability before MTTR becomes a problem at our current growth rate.”
Discussing DORA Metrics in Reports
When writing about DORA metrics in engineering reports or strategy documents, use precise language:
| Instead of | Use |
|---|---|
| ”We deploy a lot" | "Our deployment frequency is 8.3 deployments per week on average" |
| "We’re getting faster" | "Lead time for changes improved from 6 days to 2.5 days over the last quarter" |
| "We had some failures" | "Change failure rate was 18% in March, compared to our target of below 10%" |
| "We recovered quickly" | "Median MTTR for P1 incidents was 28 minutes in Q1” |
Example Sentences
- “Our deployment frequency increased from weekly to daily after we moved to trunk-based development and implemented automated smoke tests.”
- “Lead time for changes is currently three days — the longest stage is the code review queue, which averages 36 hours.”
- “Following three consecutive high-severity incidents, the change failure rate reached 30% in February, prompting a temporary deployment freeze.”
- “MTTR improved significantly after we centralised our runbooks and added automated alerting for the most common failure modes.”
- “In our DORA assessment, we classified as a ‘high performer’ on deployment frequency and MTTR, but ‘medium’ on lead time — that’s our focus area for this half.”