November 10th, 2025 by Adam Sandman
The DevOps Research and Assessment (DORA) metrics revolutionized how the software industry measures software organization performance and delivery capabilities. Developed through rigorous research based on data from thousands of companies, these metrics quickly became a standard for measuring software organization performance. In this article we explain what the four DORA metrics are, and how you can use Spira to report them for you.
What Are the Four DORA Metrics?
The four DORA metrics are:
- Lead time to change: time from code commit to deployment
- Change failure rate: percentage of failed changes in the production environment
- Deployment frequency: how often code is deployed to production
- Mean time to recover (MTTR): how fast teams can recover from a failure. This metric is also called “Failed deployment recovery time.”
Together, they give a balanced view of speed and stability: two measure flow and throughput, two measure quality and resilience. They’re technology-agnostic and can be instrumented from your CI/CD, incident, and version-control systems.
They’re important because they correlate with better organizational outcomes—happier teams, faster delivery, more reliable services, and ultimately better business performance. Tracking them helps teams spot bottlenecks (e.g., long code review cycles), reduce risk (by shrinking batch sizes and automating tests), and focus improvement work where it matters. Used well, DORA metrics become a shared language across engineering, product, and leadership to align goals, benchmark against high performers, and continuously improve both developer experience and customer value.
Using Spira to Track DORA Metrics
Spira is a great choice for tracking and measuring the four DORA metrics. Spira’s integrations with CI/CD tools such as GitHub and GitLab pull commits, branches, PRs/MRs, build and deployment events from GitHub Actions or GitLab CI. That gives you the time-stamped breadcrumbs needed for all four DORA metrics without manual spreadsheets. Spira lets you standardize what counts as a “deployment,” which environments to include (e.g., only prod), and how failures are classified. That consistency means your DORA trends are apples-to-apples across teams. Spira provides end to end traceability from requirements → user stories → tasks → commits/PRs → builds → automated tests (Rapise or other) → deployments → incidents. Because Spira links all these artifacts, you can drill from a red DORA KPI straight to the exact change, test evidence, and incident.
In addition to providing the core DORA metrics, using Spira together with the different CI/CD platforms has added benefits beyond doing it manually:
- Quality signal baked in. Tie CI test runs and coverage into the same system so DORA trends are shown alongside failing tests, flaky suites, or missing coverage. That context turns a metric into an action plan.
- Governance for regulated teams. Spira’s workflows, audit trails, baselines, and approvals provide the compliance layer (who changed what, when, and why) that pure CI/CD tools don’t emphasize—useful for regulated industries such as life sciences, finance, and government.
- Root-cause and learning loops. When a deploy is marked failed and an incident is opened, Spira links the deployment to the incident and postmortem tasks. You get MTTR and CFR that are explainable with one click.
Portfolio roll-ups: With SpiraPlan, you can aggregate the DORA metrics across many projects and programs for executive views while preserving team-level drill-down.
Tag-based commit linking: Use commit/PR keywords like [RQ:123] [IN:45] to auto-associate code to requirements and incidents—keeping the graph clean with minimal effort.
We now look at each of the four metrics and how to map them to Spira reports:
DORA Metric: Lead Time To Change
The Lead Time to Change measures how long it takes a code change to reach users, defined as the elapsed time from when a change is integrated (typically a PR is merged to the main branch) to when a successful production deployment that includes that change finishes. It captures the speed of your delivery pipeline.
Shorter lead times generally indicate smoother, more automated paths to production and tighter feedback loops, especially when paired with healthy deployment frequency; longer times can reveal bottlenecks in reviews, builds, approvals, or release practices.
When implementing this DORA metric in Spira, we are making use of the following artifacts:
- Pull Request Tasks (which sync from CI/CD tools such as GitHub)
- Releases
In general, the lead time is calculated as the average duration between creation and merging of a Pull Request (PR). Using the Tasks view, we can find the difference in time between when the PR task was opened and closed. However since we want to look at our productivity improvement over time, we group the PRs by release and then average the PR duration over the release. See the detailed KB article for more details.
DORA Metric: Deployment Frequency
Deployment Frequency is how often your organization successfully deploys code to production, typically counted as the number of production releases per service (or product) over a standard interval (e.g., per day or per week). It reflects delivery cadence and should be normalized by system/team to avoid masking variation; only successful production deployments are counted, while rollbacks are excluded or tracked separately.
When implementing this DORA metric in Spira, we are making use of the following artifacts:
- Builds (which sync from CI/CD tools such as GitHub)
- Releases
In general, the deployment frequency is determined by dividing the total number of successful deployments by the number of days in the given period. A successful deployment is defined as a build pipeline that has a status of 'Success' and is for the 'main' branch. For those projects using the GitFlow methodology, the 'develop' branch may be the appropriate branch instead. See the detailed KB article for more details.
DORA Metric: Change Failure Rate
Change Failure Rate is the percentage of production deployments that cause a service degradation and require remediation—such as a rollback, hotfix, or incident—within a defined window. Compute it as: failures ÷ total successful production deployments (e.g., in the last 30 or 90 days), where “failure” is operationally defined up front (sev-1/2 incidents, rollbacks, emergency patches, feature flags forced off, etc.).
When implementing this DORA metric in Spira, we are making use of the following artifacts:
- Releases
- Incidents
- Builds (which sync from CI/CD tools such as GitHub)
In general, the change failure rate is calculated by dividing the number of incidents by the total number of successful deployments. Incidents are defined as P1 bugs in work items. Successful deployment are defined as a build pipeline that has a status of 'Success' and is for the 'main' branch. For GitFlow environments it would be the 'develop' branch instead. See the detailed KB article for more details.
DORA Metric: Mean Time To Recover
Mean Time to Recover (MTTR) measures how quickly you restore normal service after a production incident, defined as the elapsed time from incident start or detection (e.g., alert fired, SLO breach began) to service restoration (impact ended/SLO back in compliance).
When implementing this DORA metric in Spira, we are making use of the following artifacts:
- Releases
- Incidents
- Builds (which sync from CI/CD tools such as GitHub)
In general, the mean time to recover (MTTR) is calculated by the average time it takes to close an incident within a period of time. Incidents are defined as P1 bugs. See the detailed KB article for more details.
