DORA Metrics in Plain English: How to Discuss Deployment Frequency and MTTR

DORA metrics — developed by the DevOps Research and Assessment team — are the most widely used framework for measuring software delivery performance. If you work in a modern engineering team, you will encounter these metrics in team meetings, leadership reviews, and hiring interviews. This guide explains each metric in plain English and gives you the vocabulary to discuss them confidently.

The Four DORA Metrics Explained

Deployment Frequency

What it measures: How often your team deploys code to production.

Plain English explanation: “Deployment frequency tells us how often we are actually releasing software to real users. A team that deploys multiple times a day can experiment quickly and fix problems fast. A team that deploys once a month carries much more risk in each release and learns much more slowly.”

DORA performance levels:

• Elite: Multiple deploys per day
• High: Once per day to once per week
• Medium: Once per week to once per month
• Low: Less than once per month

Phrases for discussing it:

• “Our deployment frequency has improved from weekly to daily since we introduced continuous deployment.”
• “We are currently in the ‘medium’ DORA band for deployment frequency; our goal for Q3 is to reach ‘high’.”

Lead Time for Changes

What it measures: The time from a code commit being made to that code running in production.

Plain English explanation: “Lead time tells us how quickly an idea can become a live feature. A short lead time means the team can respond rapidly to customer feedback and business needs. A long lead time means changes sit waiting in queues — in review, in testing, or waiting for a deployment window.”

Common vocabulary:

• Cycle time — the time from starting work to completing it (overlaps with, but is not identical to, lead time).
• Deployment window — a scheduled period during which deployments are permitted; a cause of long lead times in less mature teams.

Phrases for discussing it:

• “Our lead time for changes has come down from two weeks to three days since we automated the integration test suite.”
• “The main contributor to our long lead time is the manual security review step — we are exploring ways to shift that left.”

Change Failure Rate

What it measures: The percentage of deployments that cause a production failure requiring a rollback, fix-forward, or hotfix.

Plain English explanation: “Change failure rate tells us how often our deployments go wrong. A high rate means our releases are risky and our testing is not catching issues before they reach users. Elite teams have a change failure rate of 0–5%; many teams hover around 10–15%.”

Phrases for discussing it:

• “Our change failure rate was 18% last quarter — significantly above the DORA high-performer benchmark of 5–10%. We are prioritising test coverage in our core checkout flow to bring it down.”
• “The spike in change failure rate in March correlates directly with the two large releases we pushed without adequate staging testing.”

Mean Time to Recover (MTTR)

What it measures: The average time to restore service after a production incident.

Plain English explanation: “MTTR tells us how quickly we can fix things when they go wrong. No system is perfectly reliable, so MTTR is as important as trying to prevent failures. An elite team recovers in under an hour. A struggling team might take days.”

Key distinction: MTTR is not the same as Mean Time Between Failures (MTBF), which measures reliability. MTTR measures recovery speed.

Phrases for discussing it:

• “Our MTTR improved from 4 hours to 45 minutes after we invested in observability tooling and runbook automation.”
• “The incident last week had an MTTR of 6 hours — well above our target. The post-mortem identified that the detection lag was 90 minutes; we had no alerting on the specific database metric that was the root cause.”

How to Present Metric Trends

When presenting DORA metrics to a team or to leadership, use trend language rather than point-in-time values. Trends tell a story; single values do not.

Positive trend language:

• “Deployment frequency has improved steadily over the past quarter, from once per week to three times per week.”
• “MTTR has trended downward since we introduced the new runbook library — we are seeing consistent improvement month-on-month.”
• “Our change failure rate dropped from 15% in Q1 to 8% in Q2, which we attribute to the introduction of feature flags.”

Negative trend or concern language:

• “We are seeing a worrying uptick in change failure rate over the past six weeks, which warrants investigation.”
• “Lead time has plateaued — it stopped improving in April, and we believe the bottleneck is now in the code review stage rather than the deployment pipeline.”

What to Say When Metrics Are Poor

Being honest about poor metrics while presenting a credible improvement plan builds more trust than minimising the problem.

Framing poor results constructively:

• “Our MTTR of 4.5 hours is not where it needs to be. The root cause is our lack of observability in the payments service; we have a concrete plan to address this in the next sprint.”
• “I want to be transparent: our deployment frequency is in the ‘low’ DORA band. This is a structural issue — we have long-running feature branches and a slow test suite. Here is our plan to address both.”
• “The change failure rate data is uncomfortable but valuable — it tells us exactly where our quality process is breaking down.”

Example Team Meeting Sentences

1. “Looking at last month’s DORA metrics: deployment frequency held steady at daily, lead time improved slightly from 4 days to 3.5 days, but change failure rate crept up to 12% — we need to understand what drove that.”

2. “The 6-hour MTTR on Tuesday’s incident was our worst of the quarter; the post-mortem found two contributing factors: a 2-hour detection lag and a missing runbook for that failure mode. Both are addressable.”

3. “Our goal for Q3 is to move from the DORA ‘medium’ band to ‘high’ on deployment frequency — that means going from weekly to daily deployments, which requires us to break up our current monolithic release process.”

4. “I want to flag that lead time has been flat for eight weeks; we have removed the pipeline bottleneck, which means the constraint is now elsewhere — probably in the code review queue, which averages 2 days per PR.”

5. “The improvement in MTTR from 3 hours to 35 minutes over the quarter is the most encouraging signal in this data — it shows the on-call runbook work from last quarter is paying off.”