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

# DORA Metrics

> The four DORA keys, how DevPerform derives them, and how the bands work.

DORA (DevOps Research and Assessment) defines four widely-used measures of software delivery performance. DevPerform computes all four from your ingested data and shows them at the top of the **Delivery & Quality** page ("DORA — the four keys") with Elite / High / Medium / Low bands — the same page also covers cycle-time phases, CI/CD health, flaky tests, code rework, and issue-tracker planning.

## The four keys

| Metric                    | What it measures                    | How DevPerform derives it                                           |
| ------------------------- | ----------------------------------- | ------------------------------------------------------------------- |
| **Deployment Frequency**  | How often you ship                  | Merged pull requests, or successful runs of a named deploy workflow |
| **Lead Time for Changes** | How long from work to production    | Median PR open→merge (merges mode) or merge→deploy (actions mode)   |
| **Change Failure Rate**   | How often a change causes a failure | Incidents ÷ deploys in the window                                   |
| **Time to Restore**       | How fast you recover                | Median time from incident opened → resolved                         |

## Deploy signal: merges vs. actions

Deployment Frequency and Lead Time depend on knowing when you ship. DevPerform supports two modes, set per org in **Admin → Org Settings**:

<Tabs>
  <Tab title="Merges mode (default)">
    Every merged pull request counts as a deploy. Lead time is measured **PR open → merge**. This works with zero CI configuration.
  </Tab>

  <Tab title="Actions mode">
    A deploy is a **real successful deploy** from your host — a named GitHub Actions workflow run, or a GitLab / Bitbucket Deployment (you provide the workflow or environment name). Lead time is measured **merge → deploy**, attributing each shipped PR to the deploy that carried it. Use this when you have a real deploy pipeline and want production-accurate timing.
  </Tab>
</Tabs>

## Where failures come from

Change Failure Rate and Time to Restore need incident data. DevPerform treats **issues carrying your org's incident label** as incidents (GitHub/GitLab labels; Bitbucket matches on title) — no separate incident tool required. Set the label in Org Settings. CFR is incidents ÷ deploys over the window; Time to Restore is the median open→close time of those issues.

## Bands

Each key is labeled **Elite**, **High**, **Medium**, or **Low** against published DORA thresholds, so you can see at a glance where a team sits without memorizing target numbers. Bands are reference points for improvement, not grades.

<Note>
  DORA is part of the **Growth** plan and up. See [Plans](/plans).
</Note>