DORA Configuration
DORA (DevOps Research and Assessment) metrics are a widely adopted framework for measuring software delivery performance. Logilica tracks the four core DORA metrics and provides configurable settings to tune how they are calculated for your organisation.
The Core DORA Metrics
Deployment Frequency
How often your team deploys to production
Logilica counts detected deployment events over the selected time window
Lead Time for Changes
Time from code commit to production deployment
Logilica measures the elapsed time from code commit to the linked production deployment
Change Failure Rate
Percentage of deployments that cause failures
Logilica computes the share of deployments that result in a failure
Failed Deployment Recovery Time
How quickly your team recovers from deployment failures
Logilica measures how long it takes to restore a healthy deployment state after a failure
The DORA framework continues to evolve. The metric formerly known as "Mean Time to Recovery (MTTR)" was renamed to Failed Deployment Recovery Time in 2023 to scope it specifically to deployment-caused failures rather than all service disruptions. The 2024 State of DevOps Report also introduced a fifth metric — Deployment Rework Rate (the percentage of deployments that are unplanned fixes for production issues) — and restructured the framework into two categories: Software Delivery Throughput and Software Delivery Stability.
Performance Tiers
Logilica benchmarks your DORA metrics against the following performance tiers:
Elite
Multiple times per day
< 1 hour
0–15%
< 1 hour
High
Daily to weekly
1 day – 1 week
16–30%
< 1 day
Medium
Weekly to monthly
1 week – 1 month
16–30%
< 1 week
Low
Less than monthly
> 1 month
31–45%
> 1 week
About these benchmarks: DORA performance tiers are derived from annual cluster analysis of survey data — they are not fixed industry thresholds and shift year to year. More recent DORA reports use tighter ranges for some metrics (e.g., Elite Change Failure Rate at 0–5%). The 2025 report moved away from tiers entirely, replacing them with team archetypes based on broader dimensions including well-being and friction. Use the table above as a directional reference for your team's improvement journey, not as a rigid scorecard.
Using DORA Metrics Effectively
DORA metrics are powerful when used correctly, but they come with well-documented risks:
Descriptive, not diagnostic. DORA metrics tell you how you're performing, not why. A spike in recovery time could be caused by a team reorg, a complex incident, or a tooling change — the metric won't tell you which. Always pair metrics with qualitative context.
Avoid making metrics into targets. The DORA team themselves warn: "making broad statements like 'every application must deploy multiple times per day' increases the likelihood that teams will game the metrics." Focus on trends and improvement, not hitting specific numbers.
Don't compare teams on DORA alone. Different teams have different work types, domain complexity, and release cadences. Cross-team comparisons without context produce unhealthy competition rather than improvement. The DORA team explicitly cautioned against league tables.
All four metrics together. Optimising one metric at the expense of others (e.g., inflating deployment frequency with trivial changes, or reducing change failure rate by deploying nothing) defeats the purpose. The four metrics are designed to balance each other.
Configuring Deployment Detection
DORA metrics require Logilica to know which events represent production deployments. This is configured through Release Detection — see Release Detection for the full setup guide.
Logilica supports four detection methods:
Release
Detects GitHub or GitLab native release events
Build
Matches CI build job names against a regex pattern on a target branch (e.g., build jobs matching deploy.* on the main branch)
Merge
Detects merges into a specific branch matching a regex (e.g., ^production$)
Pull Request
Detects PR merges matching a regex pattern
Detection patterns are configured at Settings -> Organisation -> Release Detection and can also be overridden per-project from individual project settings.
DORA metrics will be empty if no deployment detection method is configured. The CI/CD importers import build data but do not automatically determine which builds are deployments — you must configure Release Detection or upload deployment events via the Import API.
DORA Settings
Organisation Administrators can fine-tune DORA calculation parameters at Settings -> Organisation -> DORA Settings. This page allows you to adjust platform-level constants that control how Logilica detects production failures and calculates recovery times.
Settings support three levels of precedence:
Platform defaults — industry-standard values
Organisation overrides — your domain-specific adjustments
Profile overrides — team or project-specific tuning
You can reset any override to return to the platform default.
Viewing DORA Metrics
Once deployment detection is configured and data is flowing, DORA metrics appear in:
Build Stability workstream under the Improve section
Build dashboard under the SDLC section
Weekly email reports (if AI insights are enabled for your organisation)
Good to Know
Recovery time is build-based, not incident-based. Logilica derives recovery from your CI build history rather than from an incident management system, so it reflects pipeline recovery rather than service-incident MTTR.
Humanitec deployments are tracked separately. If you use the Humanitec connector, deployment data from Humanitec environments feeds into DORA metrics through a dedicated pathway. See Connecting Tools for Humanitec setup.
Historical data matters. DORA metrics are most useful with several weeks of deployment history. Allow time for enough data to accumulate before drawing conclusions from the trends.
AI-generated code can distort DORA signals. The 2025 State of DevOps Report found that AI adoption improves individual throughput but correlates with increased delivery instability. If your team uses AI coding tools, consider interpreting deployment frequency and change failure rate in the context of your AI code share.
Last updated