Log in Get started
Metric · DORA

What are the DORA metrics, and how do you track them in Metabase?

DORA metrics are four measures of software delivery performance from the DevOps Research and Assessment program: deployment frequency, lead time for changes, change failure rate, and time to restore service (often called MTTR). Together they balance throughput (how fast you ship) against stability (how safely). Measure them in Metabase from GitHub or GitLab data synced into a database, joined with deploy and incident records.

TL;DR — Two throughput metrics (deployment frequency, lead time for changes) and two stability metrics (change failure rate, time to restore). A merge is not a deploy — anchor all four to real production deployments and incidents.

The four keys

MetricQuestion it answersSource data
Deployment frequencyHow often do we ship to production?Successful production deployments
Lead time for changesHow long from commit to production?Commits joined to the deploy that shipped them
Change failure rateWhat share of deploys cause a failure?Deployments joined to incidents/rollbacks
Time to restore (MTTR)How fast do we recover from failures?Incident start → resolve timestamps

The first two measure throughput; the last two measure stability. Healthy teams improve both together — speed without stability just ships bugs faster.

Performance bands (directional)

DORA groups teams into Elite / High / Medium / Low. The exact thresholds shift with each annual report, so treat these as directional, not a scoreboard:

MetricEliteHighMediumLow
Deployment frequencyOn-demand (multiple/day)Daily–weeklyWeekly–monthly< monthly
Lead time for changes< 1 day1 day–1 week1 week–1 month> 1 month
Change failure rate≤ 15%≤ 15%~16–30%> 30%
Time to restore (MTTR)< 1 hour< 1 day1 day–1 week> 1 week
Use bands for direction, not ranking. Compare a team to its own trend over time. Cross-team leaderboards invite gaming and ignore context.

What data do DORA metrics need?

  • Deployments — a production deploy record with environment, status, created_at, and the sha shipped (GitHub Deployments/Actions, GitLab environments/pipelines, or your CD tool).
  • Commits — sha + committed_at to compute lead time for changes.
  • Incidents — started_at/resolved_at (and ideally a link to the offending deploy) for change failure rate and MTTR. Comes from PagerDuty, Opsgenie, incident.io, or an issues label.

How do you build DORA metrics in Metabase?

  1. Sync GitHub or GitLab into a database, plus your incident source.
  2. Model a clean deployments table (one row per production deploy) and an incidents table.
  3. Define each metric once as a saved question or model, then assemble a DORA dashboard. See the GitHub or GitLab AI prompt for a starting layout.

Common mistakes

Counting merges as deployments.→ Anchor to real production deploys/releases, not merged PRs/MRs.
Reporting only throughput.→ Ship fast and safely — always pair with change failure rate and MTTR.
Averaging durations.→ Lead time and MTTR are right-skewed; use median and p90.
Cross-team leaderboards.→ Track each team against its own trend, not a ranking.

Integrations

GitHub + MetabaseSoftware deliveryGitLab + MetabaseSoftware deliverySoftware delivery analyticsOverview

Metrics

Deployment frequencyLead time for changesChange failure rateTime to restore (MTTR)

Dashboards

Software delivery dashboard

FAQ

What does DORA stand for?
DevOps Research and Assessment — the research program (now part of Google Cloud) behind the four key delivery metrics and the annual State of DevOps report.
Is MTTR officially a DORA metric?
DORA calls it "time to restore service." MTTR (mean time to recovery) is the common shorthand; report it as a median, not a mean.
Can I get DORA metrics from GitHub or GitLab alone?
Deployment frequency and lead time for changes, yes. Change failure rate and MTTR also need incident data linked to deploys. See GitHub and GitLab.