1. Start with production
Designate production pipelines and separate their deployment frequency and lead time from non-production activity.
Explore integrationsDORA Metrics
Measure production releases separately from development deployments. Read delivery speed, release stability, and lead time together to find where changes slow down.
Software delivery performance for production pipelines
Lead time increased; review where changes wait before production.
Production release frequency declined 48% versus the previous period.
Change failures increased; review recent releases that required remediation.
Production service recovery averaged 10h 42m in this period.
Production deployments fell from 36 in August to 22 in September, while remaining above April’s level.
Review the production delivery trend alongside development time, waiting for deploy, and deployment time.
From metrics to action
A change in a metric is the start of the investigation. Connect it to the work, pipeline, and quality signals that explain what happened.
Designate production pipelines and separate their deployment frequency and lead time from non-production activity.
Explore integrationsUse the lead time breakdown and delivery symptoms to find slow reviews, unreviewed pull requests, and time waiting for deployment.
Explore delivery symptomsReview the trend after changing the workflow. Compare delivery speed with failures, recovery, and quality to understand the result.
Explore Team PerformanceWhat to measure
DORA’s current framework includes five metrics. Oobeya’s production dashboard brings core delivery measures and their workflow context into the same review.
Throughput
Elapsed time from a committed change to its production deployment.
Where does a change spend time before release?
Follow the development, waiting, and deployment stages to locate delays.
Throughput
How often changes are deployed to production over a defined period.
Is production delivery becoming more consistent?
Designate production pipelines so development deployments do not inflate the release cadence.
Throughput
Time needed to recover from a failed deployment requiring intervention.
How quickly can the service recover after a release fails?
Review recovery events alongside the affected production release. The product preview uses the label Time to Restore Service.
Instability
Share of deployments requiring immediate intervention, such as a rollback or hotfix.
Are more releases leading to production problems?
Read failure rates alongside deployment volume and quality trends.
Instability
Share of deployments that are unplanned work following a production incident.
How much release activity is spent responding to incidents?
This fifth DORA metric needs incident-to-deployment mapping. Discuss calculation coverage for your connected systems in a walkthrough.
Metric definitions: DORA’s software delivery performance metrics (opens in a new tab).
Measurement context
Keep the scope and calculation definitions consistent so the next review shows whether your delivery process changed.
Explore engineering benchmarksA practical guide for CTOs, VPs, engineering managers, and platform teams who want to connect DORA metrics with flow, quality, and planning data.
The current framework includes change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. It has evolved from the original Four Keys.
Designate your production pipelines to measure Deployment Frequency and Lead Time separately from non-production pipelines. This keeps development deployment activity separate from production delivery.
The production view separates development time, time waiting for deployment, and deployment time. Use these stages to investigate where a change is delayed, then follow related workflow and review signals.
The preview shows Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Time to Restore Service. Deployment Rework Rate needs incident-to-deployment mapping; review source coverage and calculation requirements for your environment in a walkthrough.
Failed deployment recovery time specifically concerns recovery after a failed deployment requiring intervention. Broader MTTR measurements can include other incident types, so check the event scope before comparing them.
Oobeya connects source control and CI/CD systems. Define production pipelines and service boundaries consistently, and review the integrations available for your stack.
Start with your service’s baseline and compare trends using consistent definitions. Review speed, failures, and recovery together, and account for the application and release process when interpreting a benchmark.
Read AI contribution alongside production delivery, review effort, quality, and rework. An increase in AI-written code does not by itself show an improvement in delivery; use the surrounding trends to investigate outcomes.
See Oobeya in practice
Review your pipelines, delivery bottlenecks, and DORA measurement scope in a walkthrough tailored to your engineering workflow.