> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devhelm.io/llms.txt
> Use this file to discover all available pages before exploring further.

# DORA Metrics

> How DORA metrics measure software delivery performance and operational reliability

The four DORA metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service — measure engineering team performance across both velocity and stability.

## The four metrics

### 1. Deployment frequency

How often your team deploys to production.

| Performance | Frequency                          |
| ----------- | ---------------------------------- |
| Elite       | On-demand (multiple times per day) |
| High        | Weekly to monthly                  |
| Medium      | Monthly to every six months        |
| Low         | Less than once every six months    |

### 2. Lead time for changes

Time from code commit to running in production.

| Performance | Lead time             |
| ----------- | --------------------- |
| Elite       | Less than one day     |
| High        | One day to one week   |
| Medium      | One week to one month |
| Low         | More than six months  |

### 3. Change failure rate

Percentage of deployments that cause a failure requiring remediation (rollback, hotfix, or patch).

| Performance | Failure rate |
| ----------- | ------------ |
| Elite       | 0–15%        |
| High        | 16–30%       |
| Medium      | 16–30%       |
| Low         | 46–60%       |

### 4. Time to restore service (MTTR)

How long it takes to recover from a failure in production.

| Performance | Recovery time        |
| ----------- | -------------------- |
| Elite       | Less than one hour   |
| High        | Less than one day    |
| Medium      | One day to one week  |
| Low         | More than six months |

## Why DORA matters

DORA research (now part of Google Cloud) demonstrated that these four metrics predict both software delivery performance and organizational performance. Teams that excel on all four metrics:

* Deploy more frequently with fewer failures
* Recover faster when things break
* Have higher employee satisfaction
* Deliver more business value

The key insight: **velocity and stability are not tradeoffs**. Elite teams are both fast and reliable.

## How monitoring helps

Uptime monitoring directly impacts two DORA metrics:

### Change failure rate

Monitoring immediately tells you whether a deployment caused a failure. Without monitoring, failed deployments can go undetected for hours, distorting your metrics.

### Time to restore service

Faster detection (MTTD) means faster restoration (MTTR). Automated monitoring with clear alerting is the foundation of rapid recovery.

## Improving DORA metrics

| Metric               | Improvement strategy                                      |
| -------------------- | --------------------------------------------------------- |
| Deployment frequency | Smaller PRs, CI/CD automation, feature flags              |
| Lead time            | Automated testing, trunk-based development, fast CI       |
| Change failure rate  | Better testing, canary deploys, monitoring-gated rollouts |
| Time to restore      | Automated rollback, playbooks, alerting with context      |

## Monitoring as Code and DORA

Monitoring as Code specifically improves DORA metrics by:

* **Deployment frequency** — monitoring config deploys alongside code changes
* **Lead time** — automated validation catches issues in CI, not production
* **Change failure rate** — monitoring changes are reviewed in PRs like code
* **MTTR** — consistent monitoring setup across environments speeds diagnosis

<CardGroup cols={2}>
  <Card title="MTTR & MTTD" icon="clock" href="/learn/incidents/mttr-mttd-explained">
    The incident metrics that feed into DORA's MTTR.
  </Card>

  <Card title="CI/CD patterns" icon="rotate" href="/mac/ci-cd/overview">
    Automate monitoring deploys to improve all four metrics.
  </Card>
</CardGroup>