DORA metrics
Four signals that balance delivery speed with stability: deploy frequency, change lead time, recovery time, and failed-change rate.
What it is
The classic DORA metrics are four measures of software delivery: deployment frequency, lead time for changes, time to restore service, and change failure rate. They come from the DORA research program behind the annual State of DevOps reports, which Nicole Forsgren, Jez Humble, and Gene Kim wrote up in the 2018 book *Accelerate*, and the set deliberately pairs throughput with stability instead of treating raw release count as success.
Reach for them when a team wants a shared view of how quickly a committed change reaches production and how often delivery causes trouble. Pull timestamps from source control, deployment records, and incidents rather than asking people to reconstruct them in a quarterly survey.
Gotcha: they are signals, not individual targets. Teams can inflate deployment frequency by counting trivial jobs, shrink lead time by changing when the clock starts, or hide failed changes by calling every repair planned work. Define one production deployment, one change, and one failure before comparing periods or services.
Ask AI for it
Build a DORA metrics pipeline in BigQuery from the GitHub Deployments API and PagerDuty incidents. Store immutable deployment, commit, service, environment, and incident timestamps; count only successful production deployments; and join incidents to the deployment that caused them by service and commit SHA. Calculate deployment frequency, median commit-to-production lead time, median time from incident start to service restore, and change failure rate for rolling 7-day and 30-day windows. Add data-quality checks for duplicates, missing SHAs, clock order, and unlinked incidents, then create a Looker Studio dashboard with trends and the exact metric definitions beside every chart.