Implementing DORA metrics: a practical guide for 2026

Take an e-commerce team, a fictitious but typical case, that deploys once a month with a 35 % failure rate. Six months of measurement and improvement guided by the DORA metrics can bring it to several deployments a day with a failure rate of a few per cent. These indicators, validated by more than a decade of DORA research, remain the essential standard for measuring software delivery performance: this guide shows you how to collect them automatically, correlate them with incidents and display them in an actionable dashboard, without building disproportionate infrastructure.

The DORA metrics (DevOps Research and Assessment) are not just numbers to put on a dashboard. Taken one by one, each is easy to game: you can inflate Deployment Frequency by artificially splitting releases, or crush the Change Failure Rate by no longer declaring minor incidents. Reading them together is what gives them diagnostic value, because these four indicators constrain one another: shipping faster (Deployment Frequency, Lead Time) without degrading reliability (Change Failure Rate, MTTR) requires tests and automation that really hold.

This guide is for teams that already run a CI/CD pipeline in production and want to move from a hunch ("we ship faster than before") to an objective measurement. It covers collecting the raw data, computing each metric, building a Grafana dashboard, and a tour of the recent changes to the DORA framework.

What you will learn

• Instrument your CI/CD pipelines (GitHub Actions, GitLab CI, ArgoCD) to emit usable deployment events.
• Compute the 4 historical DORA metrics, Deployment Frequency, Lead Time, Change Failure Rate and MTTR, from real data.
• Correlate deployments and incidents to make the Change Failure Rate reliable, without false positives.
• Build an actionable Grafana dashboard with performance thresholds aligned with the DORA levels.
• Place your team against the recent changes to the framework: the 5th metric, Rework Rate (2024), and the end of the Elite/High/Medium/Low categories (2025).
• Choose between an in-house solution, a SaaS tool or a native feature of your CI/CD platform, depending on your context.

Prerequisites

You need a CI/CD pipeline whose deployments leave a trace, a basic observability setup (in French) to date incidents, the DORA fundamentals to know what each metric measures, and an incident management process that records the start and end of every outage.

Why measure with DORA?

Before diving into the technical implementation, let's see why these metrics were chosen among hundreds of possible measures, and what has changed in the framework in recent years.

The DORA programme, started by Gene Kim, Jez Humble and Nicole Forsgren, has studied software delivery practices for more than ten years. The most quoted figures, an Elite team deploying 208 times more often than a Low team, with recovery 2,604 times faster, come from the 2019 report and still circulate in the industry. The 2024 report, the tenth in the series, draws on nearly 3,000 respondents (around 39,000 over ten years of research) and gives similar gaps: compared with Low teams, Elite teams deploy 182 times more often, with a lead time 127 times shorter, a failure rate 8 times lower and recovery 2,293 times faster. The orders of magnitude move from one edition to the next, but the conclusion has held for more than ten years: the performance gap between the best- and worst-equipped teams is counted in hundreds, even thousands, of times.

In 2025, the methodology changed in nature: the State of AI-assisted Software Development report draws on nearly 5,000 respondents, complemented by more than 100 hours of qualitative interviews, to study the impact of generative AI on delivery. The concrete result for this guide: DORA dropped the fixed categories Low/Medium/High/Elite in favour of the distribution of responses for each metric and seven team profiles (for example "Pragmatic Performers" or "Harmonious High-Achievers"). The levels table further down in this guide nevertheless remains a practical reference point, the one from the last report that published levels.

Historically, these metrics work in pairs along two dimensions. The first two (Deployment Frequency and Lead Time) measure your throughput, that is your speed at delivering value. The last two (Change Failure Rate and MTTR) measure your stability, that is the reliability of what you ship. Since 2024, the DORA framework calls this second dimension instability (a high failure rate signals a problem, but a low one does not guarantee a healthy system), adds a fifth metric, the Deployment Rework Rate, and now places recovery time on the throughput side, as detailed below. The goal is unchanged: improve speed and reliability at the same time, never one at the expense of the other.

Source · SVG

Esc to close, + and − to zoom, scroll to move around. 100 % − Fit + Close

The 4 DORA metrics

The following table sums up each historical metric, what it measures and its dimension in the current model published on dora.dev. These are the indicators most of this guide relies on, because they remain the most widely tooled and understood by teams.

Metric	What it measures	Dimension
Deployment Frequency (DF)	Number of successful deployments to production	Throughput
Lead Time for Changes (LT)	Time between the first commit and the release to production	Throughput
Change Failure Rate (CFR)	Percentage of deployments causing incidents	Instability
Failed Deployment Recovery Time (formerly MTTR)	Time to restore service after a failed deployment	Throughput

Swipe to see more

The performance paradox

Contrary to popular belief, speed and quality go together: in the 2024 report, Elite teams deploy the most often and fail the least (5 %). The link is not mechanical though, as the High versus Medium exception in the levels table shows.

Recovery time has changed twice. In 2023, MTTR was redefined as Failed Deployment Recovery Time, which only counts outages caused by a deployment. In 2024, it moved to the throughput side, because a team able to ship fast can also fix fast without an exceptional emergency procedure. Older material still classes it under stability: the up-to-date reference remains the official guide on dora.dev. This guide keeps the MTTR acronym, still the most common in tools.

Performance levels

How do you know whether your metrics are good? The table below shows the four levels of the 2024 DORA report (figure 1). These levels are not set in advance: they emerge every year from a cluster analysis of the responses, so their bounds move from one edition to the next.

Metric	Low	Medium	High	Elite
Deployment Frequency	Between once a month and once every 6 months	Between once a week and once a month	Between once a day and once a week	On demand (several a day)
Lead Time	Between 1 and 6 months	Between 1 week and 1 month	Between 1 day and 1 week	Less than a day
Change Failure Rate	40 %	10 %	20 %	5 %
Recovery time	Between 1 week and 1 month	Less than a day	Less than a day	Less than an hour
Share of respondents	25 %	35 %	22 %	19 %

Swipe to see more

The Change Failure Rate row is surprising: in 2024, the Medium level fails less often (10 %) than the High level (20 %). DORA chose to call the faster teams "High" and the slower but more stable teams "Medium": a reminder that speed alone does not make performance.

Realistic progression

Do not aim for the Elite level straight away. Each level gained is a significant improvement, and moving from Low to Medium already takes several months of sustained effort.

Keep in mind, however, that this four-level split no longer matches exactly how DORA has presented its results since 2025. The organisation now publishes the distribution of responses for each metric (where a team sits among all respondents) rather than fixed thresholds, and crosses these figures with team profiles that also take human engagement and cognitive load into account. For everyday practical use, the table above nevertheless remains an excellent reference point: collection tools (Sleuth, LinearB, GitLab) still reason in levels of this kind in their dashboards.

1. Deployment Frequency (DF)

This is the metric to start with, for a practical reason: it only needs one piece of data, the timestamp of a successful deployment to production. No correlation, no matching with another system. If your instrumentation goes no further than this, you already have a usable indicator.

Understanding this metric

Deployment Frequency measures how often you deploy to production over a given period. It is the simplest metric to collect, but also the most revealing of your DevOps maturity.

A low frequency, around one deployment a month, is almost always explained by a high unit cost of releasing to production: manual validations, a negotiated maintenance window, a long or uncertain rollback procedure. Since each release is expensive, changes get batched, which further increases the risk and reinforces caution. Conversely, a high frequency reflects a low unit cost, hence automated tests reliable enough to do without a human validation and a rollback fast enough for a mistake to remain bearable.

What counts as a deployment

Only count successful deployments to the production environment. Deployments to staging or failed deployments do not count. Include all services, not only the main application.

Automated collection

The key to good measurement is automation. Every deployment must send an event to your metrics system. Here is how to implement it depending on your CI/CD platform:

GitHub Actions

.github/workflows/deploy.yml

name: Deploy to Production

on:
  push:
    branches: [main]

# No permission by default: each job asks for what it needs
permissions: {}

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
        with:
          persist-credentials: false

      - name: Deploy application
        run: ./deploy.sh

      - name: Track deployment metric
        if: success()
        env:
          METRICS_ENDPOINT: ${{ secrets.METRICS_ENDPOINT }}
          SERVICE: ${{ github.repository }}
          COMMIT_SHA: ${{ github.sha }}
        run: |
          curl -X POST "${METRICS_ENDPOINT}/deployments" \
            -H "Content-Type: application/json" \
            -d "{
              \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",
              \"environment\": \"production\",
              \"service\": \"${SERVICE}\",
              \"commit_sha\": \"${COMMIT_SHA}\",
              \"status\": \"success\"
            }"

Three details of this example are not about metrics but about workflow security, and deserve to be copied as they are. The global permissions: {} removes every right from the GITHUB_TOKEN, which each job then asks for at the minimum. The checkout action is pinned by SHA rather than by tag, since a tag can be redirected to other content, and persist-credentials: false avoids leaving the token in the runner's Git configuration. Finally, dynamic values go through the env block instead of being interpolated into the script, which prevents an unexpected value from being executed as shell.

GitLab CI

.gitlab-ci.yml

deploy_production:
  stage: deploy
  script:
    - ./deploy.sh
  after_script:
    - |
      if [ "$CI_JOB_STATUS" == "success" ]; then
        curl -X POST "$METRICS_ENDPOINT/deployments" \
          -H "Content-Type: application/json" \
          -d "{
            \"timestamp\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",
            \"environment\": \"production\",
            \"service\": \"$CI_PROJECT_PATH\",
            \"commit_sha\": \"$CI_COMMIT_SHA\",
            \"status\": \"success\"
          }"
      fi
  environment:
    name: production

ArgoCD

# ArgoCD notification with a webhook
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    notifications.argoproj.io/subscribe.on-sync-succeeded.webhook: deployment-tracker
---
# ConfigMap for the notifications
apiVersion: v1
kind: ConfigMap
metadata:
  name: argocd-notifications-cm
data:
  trigger.on-sync-succeeded: |
    - when: app.status.sync.status == 'Synced'
      send: [deployment-event]
  template.deployment-event: |
    webhook:
      deployment-tracker:
        method: POST
        body: |
          {
            "timestamp": "{{.app.status.operationState.finishedAt}}",
            "environment": "production",
            "service": "{{.app.metadata.name}}",
            "commit_sha": "{{.app.status.sync.revision}}",
            "status": "success"
          }

Improving deployment frequency

If your frequency is too low, identify the main bottleneck:

Symptom	Probable cause	Solution
Deployments grouped on Fridays	Fear of change	Feature flags, automatic rollback
Batches of 50+ commits	Code reviews too long	Limit PR size to 400 lines
Tests taking 2+ hours	Unoptimised test suite	Parallelisation, impact-based tests
Multiple manual approvals	Bureaucratic process	Trunk-based development, automated trust

Swipe to see more

2. Lead Time for Changes (LT)

This second metric is much more costly to instrument than the first, because it requires linking a deployment to the Git history that produced it. It is also the richest in lessons: its breakdown into phases points precisely at the step that slows down your delivery chain.

Understanding this metric

Lead Time measures the time elapsed between the first commit of a change and its deployment to production. This metric reveals the flow of your pipeline from end to end.

Lead Time adds up waiting times and processing times: code review, test execution, approvals, the actual deployment. In practice, waiting largely dominates processing, a ten-minute code review being able to sit in a queue for two days. The consequence is direct for your users: a six-month Lead Time means that a bug fix identified today will only reach them next semester, however fast the fix itself was written.

Difference with Cycle Time

DORA Lead Time measures commit → production. Do not confuse it with Cycle Time (start of work → end) or PR Time (PR opened → merged). Each metric has its value, but DORA specifically uses Lead Time.

Calculation method

Computing Lead Time requires correlating commits with deployments. Here is the logic:

# Lead Time calculation example
lead_time_calculation:
  # 1. Identify the deployment
  deployment:
    id: "deploy-123"
    commit_sha: "abc123"
    deploy_time: "2026-03-15T14:00:00Z"

  # 2. Find the first commit of the associated PR/branch
  first_commit:
    sha: "def456"
    time: "2026-03-14T10:00:00Z"

  # 3. Compute the difference
  lead_time: "28 hours"

Collection through an API

Two routes are possible: write the reconstruction of the commit/deployment link yourself, or delegate this work to a tool that subscribes to the events of your forge. The code below shows the first one, with a point of attention: it returns None for a commit pushed directly to the main branch, without going through a pull request.

GitHub API

import requests
from datetime import datetime

def calculate_lead_time(owner: str, repo: str, deployment_sha: str) -> float:
    """
    Computes the Lead Time in hours for a given deployment.

    The Lead Time is measured from the first commit of the PR
    to the timestamp of the production deployment.
    """
    headers = {"Authorization": f"token {GITHUB_TOKEN}"}

    # Step 1: find the PR associated with the deployed commit
    pr_response = requests.get(
        f"https://api.github.com/repos/{owner}/{repo}/commits/{deployment_sha}/pulls",
        headers=headers
    )

    if not pr_response.json():
        return None  # Direct commit without a PR

    pr = pr_response.json()[0]

    # Step 2: fetch all the commits of this PR
    commits_response = requests.get(
        pr['commits_url'],
        headers=headers
    )
    commits = commits_response.json()

    # The first commit is the oldest one
    first_commit_date = commits[0]['commit']['committer']['date']

    # Step 3: fetch the deployment timestamp
    deploy_time = get_deployment_timestamp(deployment_sha)

    # Step 4: compute the difference
    first_commit = datetime.fromisoformat(first_commit_date.replace('Z', '+00:00'))
    deployed = datetime.fromisoformat(deploy_time.replace('Z', '+00:00'))

    lead_time_hours = (deployed - first_commit).total_seconds() / 3600
    return lead_time_hours

Sleuth (SaaS)

sleuth.yaml

# Sleuth configuration for automatic collection
version: 1
projects:
  - name: my-application
    code_deployments:
      - name: production
        provider: github_actions
        environment: production

    # Sleuth automatically computes:
    # - Lead Time (first commit → deploy)
    # - Deployment Frequency
    # - Change Failure Rate
    # - MTTR
    #
    # Supported integrations:
    # - GitHub, GitLab, Bitbucket
    # - Jenkins, CircleCI, GitHub Actions
    # - PagerDuty, Opsgenie, Incident.io

Improving Lead Time

Lead Time breaks down into several phases. Identify the one that takes the most time:

Phase	Typically problematic duration	Optimisation
Code	PRs of 1000+ lines	Trunk-based development, PRs < 400 lines
Review	> 48h waiting	Limit WIP, reviews < 24h, pair programming
Build	> 30 minutes	Dependency caching, incremental builds
Tests	> 1 hour	Parallelisation, impact-based tests, shift-left
Deploy	Manual, > 1 day	Full automation, GitOps

Swipe to see more

3. Change Failure Rate (CFR)

This is the most delicate metric of the four, not to compute but to define. Its formula fits in one division; its reliability depends entirely on the convention you adopt to decide that a deployment failed. Write this convention down before collecting anything, otherwise comparisons over time will mean nothing.

Understanding this metric

The Change Failure Rate measures the percentage of deployments that cause an incident in production or require a rollback. It is the indicator of the quality of what you ship.

A CFR of 30 % means that one deployment in three had to be fixed or rolled back afterwards. The figure points to a failure of the controls before release to production: what should have been caught by tests, review or configuration validation is only caught once users are exposed. Beware of the reverse interpretation, because a very low CFR is not necessarily a good sign: it may simply reveal that incidents are not declared, or that the team deploys so rarely that the sample has no statistical value.

Defining what counts as a failure

A deployment is considered "failed" if one of these conditions is met within 24-48h after the deployment:

• A rollback is performed
• An incident is created and linked to the deployment
• An urgent hotfix is deployed
• A service degradation is detected

Calculation method

The denominator is the total number of production deployments over the period, the numerator the sum of the deployments considered failed. A single deployment followed by a rollback and a hotfix must only be counted once, or the rate could artificially exceed 100 %.

# Change Failure Rate calculation
period: "2026-03"

statistics:
  deployments_total: 100
  deployments_failed:
    rollbacks: 3
    linked_incidents: 2
    hotfixes: 1
  total_failures: 6

# CFR = (failures / total) × 100
change_failure_rate: "6%"

Collection and correlation

The difficulty of the CFR lies in the correlation between deployments and incidents. Here are two approaches:

Kubernetes annotations

# Annotations on Kubernetes Deployments
apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    # Unique deployment identifier
    metrics.dora/deployment-id: "deploy-2026-03-15-001"
    # Status updated in case of a problem
    metrics.dora/status: "success"  # or "rolled-back", "failed"
    # Timestamp for correlation
    metrics.dora/deployed-at: "2026-03-15T14:00:00Z"

Correlation script

from datetime import datetime, timedelta

def calculate_cfr(start_date: str, end_date: str) -> float:
    """
    Computes the Change Failure Rate over a given period.

    A deployment is marked as 'failed' if within 24h:
    - A rollback was performed
    - An incident was linked to the deployment
    - A hotfix was deployed
    """
    deployments = get_deployments(start_date, end_date)
    incidents = get_incidents(start_date, end_date)

    failed_count = 0
    window = timedelta(hours=24)

    for deploy in deployments:
        deploy_time = datetime.fromisoformat(deploy['timestamp'])

        # Check for a rollback within 24h
        if has_rollback_within(deploy, window):
            failed_count += 1
            continue

        # Check for a linked incident
        for incident in incidents:
            incident_time = datetime.fromisoformat(incident['created_at'])

            # The incident must fall within the 24h window
            if deploy_time <= incident_time <= deploy_time + window:
                # Check the explicit link or the service
                if is_deployment_related(incident, deploy):
                    failed_count += 1
                    break

    cfr = (failed_count / len(deployments)) * 100
    return round(cfr, 2)

Improving the Change Failure Rate

A high CFR reveals problems in your quality chain:

Frequent cause	Diagnosis	Solution
Insufficient tests	Coverage < 60%	More E2E tests, contract tests
Configuration errors	Different dev/prod configs	Infrastructure as Code, pre-deploy validation
Changes too large	PRs > 1000 lines	Smaller batches, feature flags
Different environments	"Works on my machine"	Dev/staging/prod parity, containers
Unrealistic test data	Tests pass, prod fails	Anonymised production data, chaos engineering

Swipe to see more

4. Mean Time to Recover (MTTR)

This last metric is not collected in the CI/CD chain but in the incident management tool. It therefore rests on a strong assumption: that every incident is declared, and that its detection and resolution timestamps are filled in honestly. If your incidents get settled in an informal conversation without ever being opened, this measurement will remain meaningless.

Understanding this metric

MTTR measures the average time to restore service after an incident. It is the indicator of your resilience, your ability to bounce back when things go wrong.

The premise behind this metric is that an outage will eventually happen, and that its duration is the only variable truly under your control. MTTR measures service restoration, not the final fix of the cause: a rollback that brings the application back stops the clock, even if the bug remains to be dealt with. This is exactly what explains the gap between teams: those that restore in less than an hour have an automated rollback path, the others have to produce a fix under pressure before they can redeploy.

MTTR versus other time metrics

DORA MTTR specifically measures the time to restore the service. There are other metrics such as MTTA (Time to Acknowledge), MTTD (Time to Detect), or MTTI (Time to Investigate). For DORA, focus on the total time: detection → resolution. In 2023, the official framework renamed this metric Failed Deployment Recovery Time, to count only the incidents caused by a deployment (and exclude outages of external origin, such as a cut at your hosting provider). The MTTR acronym nevertheless remains widely used in the industry and in this guide.

Calculation method

MTTR is an arithmetic mean, which makes it very sensitive to extreme values: a single incident lasting several days is enough to derail the figure for the month. Many teams also track the median to read the underlying trend, and keep the mean to spot these isolated cases.

# Monthly MTTR calculation
period: "2026-03"

incidents:
  - id: "INC-001"
    detected_at: "2026-03-05T10:00:00Z"
    resolved_at: "2026-03-05T10:45:00Z"
    recovery_time: "45 minutes"

  - id: "INC-002"
    detected_at: "2026-03-12T14:30:00Z"
    resolved_at: "2026-03-12T16:00:00Z"
    recovery_time: "90 minutes"

  - id: "INC-003"
    detected_at: "2026-03-20T03:00:00Z"
    resolved_at: "2026-03-20T03:20:00Z"
    recovery_time: "20 minutes"

# MTTR = mean of the recovery times
mttr: "(45 + 90 + 20) / 3 = 51.67 minutes"

Collection from incident tools

On-call platforms already expose the timestamps you need; what remains is to filter what you count. Two filters are essential: keep only resolved incidents, otherwise an incident that is still open skews the calculation, and keep only production services, so as not to mix in pre-production alerts.

PagerDuty

import pdpyras
from datetime import datetime
from statistics import mean

def get_mttr_from_pagerduty(start_date: str, end_date: str) -> float:
    """
    Fetches resolved PagerDuty incidents and computes the MTTR.

    Only takes resolved production incidents into account.
    Returns the MTTR in minutes.
    """
    session = pdpyras.APISession(PAGERDUTY_TOKEN)

    # Fetch resolved incidents only
    incidents = session.iter_all(
        'incidents',
        params={
            'since': start_date,
            'until': end_date,
            'statuses[]': ['resolved'],
            # Filter on production services
            'service_ids[]': PRODUCTION_SERVICE_IDS
        }
    )

    recovery_times = []

    for incident in incidents:
        created = datetime.fromisoformat(incident['created_at'])
        resolved = datetime.fromisoformat(incident['resolved_at'])

        # Recovery time in minutes
        recovery_minutes = (resolved - created).total_seconds() / 60
        recovery_times.append(recovery_minutes)

    if not recovery_times:
        return 0.0

    mttr = mean(recovery_times)
    return round(mttr, 2)

Incident.io

# Incident.io automatically computes several metrics
# available through its API or its dashboard

available_metrics:
  - time_to_acknowledge  # Time before the first response
  - time_to_mitigate     # Time before mitigation
  - time_to_resolve      # MTTR - total resolution time

# Export the metrics through the API
api_query: |
  GET /v2/metrics/incidents
  ?created_at[gte]=2026-03-01
  &created_at[lt]=2026-04-01
  &metrics[]=time_to_resolve

# Or through its query language
analytics_query: |
  incidents
  | where created_at >= ago(30d)
  | where severity in ("critical", "major")
  | summarize
      mttr_minutes = avg(resolve_duration_minutes),
      incident_count = count()

Improving MTTR

MTTR breaks down into several phases. Each one can be optimised:

Phase	What it covers	Improvement levers
Detection	Time before knowing there is a problem	Proactive alerting, well-defined SLOs, synthetic monitoring
Diagnosis	Time to understand the cause	Full observability (logs, traces, metrics), clear dashboards
Mitigation	Time to restore the service for users	One-click automatic rollback, feature flags, circuit breakers
Resolution	Time to fix for good	Up-to-date runbooks, clear escalation, post-mortems

Swipe to see more

The 5th DORA metric: Deployment Rework Rate

Since the 2024 report, DORA adds a fifth metric to the four historical ones: the Deployment Rework Rate. It measures the percentage of unplanned deployments that result directly from an incident in production, as opposed to planned deployments that move the roadmap forward.

The difference with the Change Failure Rate is subtle but useful: the CFR counts every deployment that caused an incident, while the Rework Rate counts the deployments that were triggered to respond to an incident, whether it was caused by the same service or by a dependency. A team can have a low CFR (its own changes rarely break production) but a high Rework Rate if it spends a lot of time fixing regressions coming from other teams or from external dependencies.

The calculation follows the same logic as the CFR: divide the number of unplanned deployments linked to an incident by the total number of deployments over the period. If you have already set up the deployment/incident correlation described above, you have most of the data you need: just add a planned: true/false field to every deployment event to tell a feature release from an emergency fix.

A still young metric

Few SaaS tools (Sleuth, LinearB, GitLab) expose the Rework Rate natively today: most still compute it manually or through a custom field. Do not block your implementation on this 5th metric: treat it as a complement once the 4 historical metrics are stable, not as a prerequisite.

Collection architecture

The four metrics rely on the same technical chain: sources that emit events, a collection point that normalises them, time series storage and a display layer. Laying down this structure before coding avoids redoing the instrumentation for each new metric. First check what your platform already provides: part of this work is sometimes unnecessary.

Overview of the data flow

For your DORA metrics to be reliable, you need to set up an automated collection architecture. The data comes from various sources, your code repository, your CI/CD pipeline, your incident system, and converges towards a central dashboard.

Source · SVG

Esc to close, + and − to zoom, scroll to move around. 100 % − Fit + Close

Components of the architecture

The DORA collection architecture has four distinct layers. Depending on your platform, part of this architecture already exists natively: GitLab Ultimate, for example, computes Deployment Frequency, Lead Time, Change Failure Rate and MTTR directly from its pipeline data through the Value Streams Dashboard, with no external tool needed.

Layer	Role	Example tools
Sources	Emit the raw events	GitHub, GitLab, ArgoCD, PagerDuty, Opsgenie
Collector	Aggregates and normalises the data	Python scripts, OpenTelemetry, webhooks
Storage	Keeps the time series	Prometheus, InfluxDB, TimescaleDB
Visualisation	Displays the dashboards	Grafana, Datadog, custom

Swipe to see more

Start simple

You do not need a complex architecture to get started. A simple script that collects the data once a day and stores it in a PostgreSQL database is enough for the first weeks. Only add complexity once you have validated the value of the metrics.

Grafana dashboard

Here is a Grafana configuration to display the 4 DORA metrics. Each panel uses coloured thresholds to adapt to your goals: the values below are examples, not the official bounds of the levels table.

{
  "dashboard": {
    "title": "DORA Metrics Dashboard",
    "description": "Overview of the 4 DORA metrics",
    "panels": [
      {
        "title": "Deployment Frequency (7 days)",
        "type": "stat",
        "description": "Number of successful deployments this week",
        "targets": [{
          "expr": "sum(increase(deployments_total{env=\"production\", status=\"success\"}[7d]))"
        }],
        "thresholds": {
          "steps": [
            {"color": "red", "value": 0},
            {"color": "orange", "value": 1},
            {"color": "yellow", "value": 4},
            {"color": "green", "value": 7}
          ]
        }
      },
      {
        "title": "Lead Time (hours)",
        "type": "stat",
        "description": "Average commit → production time",
        "targets": [{
          "expr": "avg(deployment_lead_time_hours{env=\"production\"})"
        }],
        "thresholds": {
          "steps": [
            {"color": "green", "value": 0},
            {"color": "yellow", "value": 24},
            {"color": "orange", "value": 168},
            {"color": "red", "value": 720}
          ]
        }
      },
      {
        "title": "Change Failure Rate (%)",
        "type": "gauge",
        "description": "Percentage of deployments causing incidents",
        "targets": [{
          "expr": "sum(deployments_failed_total) / sum(deployments_total) * 100"
        }],
        "thresholds": {
          "steps": [
            {"color": "green", "value": 0},
            {"color": "yellow", "value": 15},
            {"color": "orange", "value": 30},
            {"color": "red", "value": 45}
          ]
        }
      },
      {
        "title": "MTTR (minutes)",
        "type": "stat",
        "description": "Average time to restore the service",
        "targets": [{
          "expr": "avg(incident_recovery_time_minutes)"
        }],
        "thresholds": {
          "steps": [
            {"color": "green", "value": 0},
            {"color": "yellow", "value": 60},
            {"color": "orange", "value": 1440},
            {"color": "red", "value": 10080}
          ]
        }
      }
    ]
  }
}

Specialised DORA tools

Rather than building your own collection solution, you can use specialised tools. The market has moved: in late 2025, Atlassian acquired DX (an engineering productivity measurement platform) for about one billion dollars, a sign of the growing interest of large vendors in these tools. Here is a comparison of the main options:

Tool	Type	Strengths	Ideal for
Sleuth	SaaS	Auto-discovery, set up in 10 min	Teams that want to start fast
LinearB	SaaS	Complete engineering metrics	Teams looking for dev insights
Apache DevLake	Open source	Apache Software Foundation project, 20+ connectors (GitHub, GitLab, Jenkins, Jira)	Organisations that want to host their own data
Port	SaaS	Developer portal + built-in DORA	Mature platform engineering
GitLab Ultimate	Platform-native	Built-in Value Streams Dashboard	Teams already on GitLab Ultimate
Four Keys	Open source (archived)	Created by Google, GCP-native	Teaching reference, no longer maintained

Swipe to see more

Four Keys: the reference tool, now archived

Four Keys, the open source tool created by the DORA team at Google, long served as the reference for tooling the 4 metrics on Google Cloud Platform. The repository was archived in January 2024: it can still be browsed and forked, but Google no longer maintains it, and its README explicitly recommends using it "as inspiration" rather than as a production dependency.

# Clone the Four Keys repository (archived, unmaintained since 2024)
git clone https://github.com/GoogleCloudPlatform/fourkeys.git
cd fourkeys

# Configure the GCP project
export PROJECT_ID="my-dora-project"
export REGION="europe-west1"

# Run the deployment script
# Creates: BigQuery, Cloud Run, Pub/Sub, Cloud Build triggers
./setup/setup.sh

# Check the deployment
gcloud run services list --project=$PROJECT_ID

Maintained alternatives

If you are starting a new project, prefer an actively maintained tool: Apache DevLake for a self-hosted solution, Sleuth or LinearB for a turnkey SaaS, or the native metrics of GitLab Ultimate or GitHub if you are already on one of these platforms. Keep Four Keys for teaching purposes or for a fork you maintain yourself.

Continuous improvement cycle

Implementing the DORA metrics is not an end in itself. The goal is to use this data to improve continuously your practices, following the recommended cycle below.

Source · SVG

Esc to close, + and − to zoom, scroll to move around. 100 % − Fit + Close

This cycle takes on renewed importance with the rise of AI coding assistants. The 2025 DORA report shows that adopting generative AI increases code throughput, but often degrades stability (more rework, more incidents) when testing, review and deployment practices do not keep up. Measuring your 4 metrics before and after a large-scale rollout of AI assistants in your teams has become one of the most concrete use cases of this cycle, and connects to the issues covered by our guide on Platform Engineering, which aims precisely to absorb this extra load through better internal tooling.

The 4 phases of the cycle

These four phases run in order and each one conditions the next. The first one, the baseline measurement, is the one teams skip most often, and it is also the one without which the other three bring no evidence.

1. Measure the baseline

   Collect 2 to 4 weeks of data before attempting any improvement. This baseline will let you measure the real impact of your actions. Without a baseline, you will never know whether your changes had a positive effect.

2. Analyse the bottlenecks

   Identify which metric is the weakest and why. Use the data to find the root causes. For example, if your Lead Time is high, break it down: is it the review time? The build? The tests?

3. Improve one process

   Focus on a single metric at a time. Implement a targeted change (for example limiting PR size, parallelising tests) and give it time to produce effects (2 to 4 weeks minimum).

4. Validate the results

   Compare the new measurements with the baseline. Did the change have the expected effect? Were there side effects on the other metrics? Document the lessons learned.

Implementation plan

Here is a realistic plan to implement DORA metrics in your organisation. It is deliberately spread over three months, because the first two weeks produce no usable figure: you first need to accumulate enough events for the averages to make sense. Do not share a dashboard before checking that the data feeding it is complete: a wrong figure lastingly destroys trust in the approach.

1. Weeks 1-2: Instrumentation

   • Add the tracking webhooks to your CI/CD pipelines
   • Configure the correlation between deployments and incidents
   • Check that the data arrives correctly

2. Weeks 3-4: Baseline and dashboard

   • Deploy a basic Grafana dashboard
   • Collect the baseline over 2 full weeks
   • Share the dashboard with the teams (read-only)

3. Month 2: First improvement

   • Identify the weakest metric
   • Choose a targeted improvement action
   • Implement it and measure the impact

4. Month 3+: Culture of improvement

   • Set up a monthly review of the metrics
   • Define goals per team (realistic ones)
   • Celebrate improvements, without blaming regressions

Avoiding the metrics trap

DORA metrics must never be used to assess or compare individuals. Only use them to improve team processes. Otherwise, you will create gaming behaviours that make the metrics useless.

Guides for the collection tools

Collection plugs in where the events are born: the GitHub Actions course and the GitLab CI course (in French) show where to read deployments, Prometheus (in French) stores the time series and Grafana (in French) builds the dashboard of the four metrics.

Further resources

To dig into the theory behind these metrics or follow the evolution of the DORA framework, these external resources are authoritative on the subject. They are maintained directly by the DORA programme or by the authors of the founding book Accelerate.

Resource	Description
DORA.dev	Official site of the DORA programme, with tools and research
DORA metrics guide	Official reference for the 5 current metrics (throughput + instability)
2025 DORA report	State of AI-assisted Software Development, impact of AI on delivery
Four Keys	Google's open source DORA collection tool (archived since 2024)
Accelerate	The founding book by Nicole Forsgren, Jez Humble and Gene Kim

Swipe to see more

Key points

DORA metrics are the standard for measuring DevOps performance. Here are the key points of this guide:

• 4 historical metrics measure your performance: Deployment Frequency, Lead Time, Change Failure Rate, MTTR
• A 5th metric, the Deployment Rework Rate, was added in 2024 to separate planned deployments from emergency fixes
• 2 complementary dimensions: throughput (speed) and instability (reliability), with MTTR moved to the throughput side in the most recent version
• The 2024 report measures Elite teams deploying 182× more often than Low teams and recovering 2,293× faster; since 2025, DORA prefers the distribution of responses and 7 team profiles to fixed categories
• Collect automatically through CI/CD webhooks and correlation with incidents, or rely on your platform's native metrics (GitLab Ultimate)
• Four Keys is archived since 2024: use it as a teaching reference, not as a production dependency
• Improve one metric at a time to see the real impact, while keeping an eye on the effect of generative AI on your stability

Where to start this week

Start instrumenting your deployments now. Even manual collection in a spreadsheet is better than no data at all. Automation will come later.

Knowledge check

Check that you have the essentials of this lesson: the collection of each metric, the calculation pitfalls and the recent changes to the framework. The questions only cover what has just been explained here.

Knowledge check

Check what you have learned with this interactive quiz

8 questions

8 min

70% to pass

How it works

• The timer starts when you click Start
• Multiple choice, true/false and short answer questions
• You can move between questions
• Detailed results are shown at the end

Start the quiz

Starts the quiz and the timer

FAQ: frequently asked questions

These questions come up systematically during implementation, especially those about the scope to measure and the management use of the figures obtained.

How do you measure DORA metrics in practice?

Which tool should you choose to track DORA metrics?

What is the difference between the Change Failure Rate and the Deployment Rework Rate?

How long does it take to implement DORA metrics?

Can you get DORA metrics natively without an external tool?

Why not use Four Keys to implement DORA metrics?

×

See in the glossary →