> For the complete documentation index, see [llms.txt](https://docs.logilica.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.logilica.com/configuration/dora-configuration.md).

# 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

| Metric                              | What It Measures                                        | How Logilica Tracks It                                                                    |
| ----------------------------------- | ------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| **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 |

{% hint style="info" %}
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.
{% endhint %}

## Performance Tiers

Logilica benchmarks your DORA metrics against the following performance tiers:

| Tier       | Deployment Frequency   | Lead Time for Changes | Change Failure Rate | Recovery Time |
| ---------- | ---------------------- | --------------------- | ------------------- | ------------- |
| **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      |

{% hint style="info" %}
**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.
{% endhint %}

## 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](/configuration/release-detection.md) for the full setup guide.

Logilica supports four detection methods:

| Method           | How It Works                                                                                                                      |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| **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.

{% hint style="warning" %}
**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](/advanced/import/build-data.md).
{% endhint %}

## 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:

1. **Platform defaults** — industry-standard values
2. **Organisation overrides** — your domain-specific adjustments
3. **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](/integration/connecting-tools.md) 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.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.logilica.com/configuration/dora-configuration.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.