What this section is for
Track how quickly and reliably changes reach production. Connect CI/CD and define which deployments belong to each production service. Time to production needs the first commit; failure and recovery metrics need incidents linked to deployments. A Git connection alone cannot provide all four metrics.
When to use
- To compare deployment frequency with failures.
- Before changing the release schedule, to check current frequency and time to production.
- After a failure, to check whether similar incidents happened during the selected period.
Quick start
- 1In Settings โ DORA, connect a CI/CD provider and choose the workflow that deploys to production.
- 2Define services using repository, workflow and environment patterns. Check that staging deployments and ordinary builds are excluded from the production cohort.
- 3For failure and recovery metrics, connect your incident source and verify links to deployments.
- 4Select a period and service. Check available metrics against deployment and incident feeds; investigate missing values in the source data.
Key settings
| Setting | What it does | How to use it | Common mistake |
|---|---|---|---|
| Service definitions | Group deployments and incidents by matching repository, workflow and environment name patterns. | Start with a few services. Match the production environment precisely to exclude test deployments. | Including staging as production, which distorts deployment frequency and time to production. |
| CI/CD integration | Supplies deployment events and the commits behind them. | Select the workflow that deploys to production. A build alone is not a release. | Matching every workflow and counting CI runs as deployments. |
| Incident integration | Supplies incidents used for change failure rate and recovery time. | Check that the incident tool records the service, severity and link to a deployment. | Expecting a change failure rate when incidents are never linked to a service. |
Usage example
Scenario: In this illustrative example, the team deploys daily but more than 15% of deployments are linked to failures.
- 1Choose the service and find deployments marked as rollbacks or linked to incidents.
- 2Compare acknowledgement and recovery times in the incident timeline to check response and repair separately.
- 3Check whether repeated failures involve the same workflow or environment. Discuss those cases with the team.
What this shows: You have specific deployments and incidents to investigate, and a service or workflow to focus on.
FAQ
What data do I need to calculate DORA metrics?
Deployment frequency needs production deployment events; lead time also needs the first commit of the change. Change failure rate and recovery time require incidents linked to deployments and their resolution timestamps. Before comparing services, check that selection rules and source coverage are consistent.
Why does lead time differ from Delivery?
Delivery measures pull request opening to merge. DORA measures first commit to production. These averages may cover different changes, so subtracting one from the other does not measure release waiting time.
Can we use DORA without an incident tool?
You can review deployment frequency and, when the first commit is available, lead time. Those sources alone cannot establish complete failure or recovery reporting.
What does the maturity level mean?
The category shows which configured ranges the four service metrics fall into. Check the dates, services and completeness of the data before comparing. The category does not explain failures or evaluate the team.
Tips
- A missing first-commit date is not replaced with merge time. Recovery is the median for resolved deployment-related incidents, including zero-duration recoveries.
- The timeline displays up to 100 events. Summary metrics are calculated separately across the selected period. This section implements four DORA metrics.
- Define services before comparing periods: changing the matching patterns can change historical results.
- Compare a service with its previous results. A category label alone does not tell you what to improve.