{
  "@context": "https://schema.org",
  "@type": "Article",
  "url": "/devops-consulting/dora-metrics-guide",
  "markdownUrl": "https://www.desaiinfo.net/kb/devops-consulting/dora-metrics-guide.md",
  "publisher": {
    "name": "Desai InfoTech",
    "url": "https://www.desaiinfo.net"
  },
  "type": "article",
  "slug": "dora-metrics-guide",
  "pillar": "devops-consulting",
  "order": 6,
  "title": "DORA Metrics Guide for Small Software Teams",
  "metaTitle": "DORA Metrics Guide: Measure DevOps Performance Simply",
  "description": "The four DORA metrics - deployment frequency, lead time, change failure rate and recovery time - and how small teams can measure and improve them simply.",
  "keywords": [
    "dora metrics",
    "dora metrics guide",
    "deployment frequency",
    "lead time for changes",
    "change failure rate",
    "time to restore service",
    "devops metrics"
  ],
  "published": "2026-10-17",
  "updated": "2026-10-17",
  "summary": "DORA metrics are research-backed measures of software delivery performance from the DevOps Research and Assessment program. The four core metrics are deployment frequency, lead time for changes, change failure rate and time to restore service. Together they show whether a team delivers both fast and reliably. Small teams can measure them from their Git, CI/CD and incident data with simple scripts or built-in tools.",
  "keyTakeaways": [
    "DORA balances speed metrics (deployment frequency, lead time) with stability metrics (change failure rate, recovery time).",
    "Measure trends for your own team over time; avoid using DORA metrics to compare or rank individuals.",
    "Most data already exists in Git, pipeline and incident records, so start simple before buying tools.",
    "Improve the metrics by shrinking batch size, automating tests and deployments and improving monitoring."
  ],
  "faqs": [
    {
      "q": "What are the four DORA metrics?",
      "a": "The four core DORA metrics are deployment frequency (how often you deploy to production), lead time for changes (time from code commit to running in production), change failure rate (share of deployments causing a failure that needs remediation) and time to restore service (how long it takes to recover from a production failure). Recent DORA research has also introduced a rework-rate measure and refined some names."
    },
    {
      "q": "What is a good DORA score for a small team?",
      "a": "There is no universal target. The annual DORA research groups teams into performance clusters, and top performers typically deploy on demand with lead times under a day and quick recovery. For a small team, the useful question is whether your own metrics are improving quarter over quarter. A move from monthly to weekly deployments with a stable failure rate is real progress."
    },
    {
      "q": "What tools can measure DORA metrics?",
      "a": "GitLab includes DORA metrics in some tiers, and several engineering intelligence platforms calculate them from GitHub, Azure DevOps and incident tools. The open-source Four Keys project from Google demonstrated a reference approach, and Apache DevLake is another open-source option. Many small teams start with a spreadsheet or simple script using deployment logs and incident records."
    },
    {
      "q": "Can DORA metrics be gamed?",
      "a": "Yes, if they are used as targets for individuals or tied to performance reviews. Teams can inflate deployment counts with trivial changes or avoid recording failures. Use the metrics as team-level learning signals, look at all four together so speed gains at the cost of stability show up, and pair them with qualitative conversations in retrospectives."
    }
  ],
  "related": [
    {
      "title": "CI/CD Pipeline Best Practices for Small Teams",
      "url": "https://www.desaiinfo.net/devops-consulting/ci-cd-pipeline-best-practices"
    },
    {
      "title": "DevSecOps Guide for Small Development Teams",
      "url": "https://www.desaiinfo.net/devops-consulting/devsecops-guide"
    },
    {
      "title": "Kubernetes for Small Business - When It Makes Sense",
      "url": "https://www.desaiinfo.net/devops-consulting/kubernetes-for-small-business"
    },
    {
      "title": "Azure DevOps Best Practices for Small Teams",
      "url": "https://www.desaiinfo.net/azure-consulting/azure-devops-best-practices"
    },
    {
      "title": "How to Estimate Custom Software Development Cost",
      "url": "https://www.desaiinfo.net/software-development/software-development-cost-estimation"
    }
  ],
  "url_path": "/devops-consulting/dora-metrics-guide",
  "bodyMarkdown": "\"Are we getting better at delivering software?\" is hard to answer by gut feeling. The DORA metrics give small teams a simple, well-researched way to answer it. This guide explains each metric, how to measure it with the data you already have and which practices move the numbers. It is part of our [DevOps consulting](https://www.desaiinfo.net/devops-consulting) resources.\n\n## What are DORA metrics?\n\nDORA metrics are four measures of software delivery performance identified by the DevOps Research and Assessment (DORA) program, now part of Google Cloud, through years of industry surveys. They are widely used because they balance speed with stability.\n\n| Metric | Category | Question it answers |\n|---|---|---|\n| Deployment frequency | Throughput | How often do we deploy to production? |\n| Lead time for changes | Throughput | How long from commit to running in production? |\n| Change failure rate | Stability | What share of deployments cause a failure needing remediation? |\n| Time to restore service | Stability | How quickly do we recover when production breaks? |\n\nDORA's research has consistently found that speed and stability are not trade-offs: the strongest teams tend to excel at both. The program continues to refine its model, including adding measures such as rework rate, so check the latest State of DevOps report for current definitions.\n\n## How do you measure deployment frequency?\n\nDeployment frequency is the number of successful production deployments in a period. Count them from your CI/CD platform's deployment history.\n\n- GitHub Actions: deployments to the production environment\n- Azure Pipelines: runs of the production stage in environments history\n- GitLab: deployments to the production environment\n\nCount per service if you have several. Measure weekly or monthly and look at the trend. Small teams often start with monthly releases and move toward several deployments a week as automation improves.\n\n## How do you measure lead time for changes?\n\nLead time for changes is the time from a commit (or merged pull request) to that change running in production. Calculate it by matching commit timestamps to the deployment that shipped them, then take the median.\n\nPractical approaches:\n\n1. Tag each deployment with the commit SHA it deployed\n2. For each deployment, list the commits included since the previous deployment\n3. Calculate the time from each commit to its deployment\n4. Report the median per week or month\n\nSome teams use pull-request merge time instead of first commit time because it is simpler and excludes design and coding time. Choose one definition and keep it consistent.\n\n## How do you measure change failure rate?\n\nChange failure rate is the percentage of production deployments that cause a failure requiring remediation, such as a rollback, hotfix or incident. Divide failed deployments by total deployments in the period.\n\nDefine \"failure\" clearly before you start, for example:\n\n- A rollback or redeploy of the previous version\n- A hotfix deployed to fix a defect introduced by the change\n- An incident linked to the deployment\n\nLink incidents to deployments in your ticketing or incident tool, even with a simple label. Without that link, this metric is guesswork.\n\n## How do you measure time to restore service?\n\nTime to restore service is how long it takes to recover from a production failure, from detection or start of impact to restoration. Use the median across incidents in the period.\n\nCapture start and resolution times consistently in your incident records, whether in a dedicated incident tool, your ticketing system or a shared spreadsheet. Good monitoring and alerting matter here: you cannot restore quickly what you do not detect quickly.\n\n## How can a small team start measuring with minimal tooling?\n\nStart with a simple monthly spreadsheet or script that pulls deployments from your CI/CD platform and incidents from your ticketing system. Perfect accuracy matters far less than consistent measurement over time.\n\nStarter checklist:\n\n- [ ] Agree on definitions for deployment, failure and restoration\n- [ ] Ensure production deployments run only through the pipeline so they are recorded\n- [ ] Tag deployments with commit SHAs and versions\n- [ ] Label incidents with the related deployment\n- [ ] Record a baseline for the current quarter\n- [ ] Review the four metrics together monthly in a team retrospective\n\nIf you outgrow the spreadsheet, platforms such as GitLab's built-in analytics, Apache DevLake or commercial engineering-metrics tools can automate collection.\n\n## Which practices improve DORA metrics?\n\nSmaller changes, automated testing, automated deployments, trunk-based development and good monitoring improve all four metrics. The table maps common bottlenecks to practices.\n\n| Symptom | Likely cause | Practice to adopt |\n|---|---|---|\n| Infrequent deployments | Manual, risky releases | Automated CD with approvals; see [CI/CD pipeline best practices](https://www.desaiinfo.net/devops-consulting/ci-cd-pipeline-best-practices) |\n| Long lead time | Large pull requests, slow reviews, long-lived branches | Smaller PRs, trunk-based development, review agreements |\n| High change failure rate | Weak test coverage, environment drift | Automated tests, infrastructure as code, staging that mirrors production |\n| Slow recovery | Poor monitoring, hard rollbacks | Alerting on user-facing signals, one-step rollback, runbooks |\n| Security issues found late | Manual security review at the end | Automated scanning; see the [DevSecOps guide](https://www.desaiinfo.net/devops-consulting/devsecops-guide) |\n\n## How should leaders use DORA metrics?\n\nLeaders should use DORA metrics to find bottlenecks and track improvement at the team level, not to rank individuals or compare unrelated teams. Context matters: a nonprofit maintaining a donor portal and a SaaS startup shipping daily have different needs.\n\nGood uses:\n\n- Justifying investment in automation and testing with before-and-after data\n- Spotting when speed gains are eroding stability\n- Setting quarterly improvement goals the team chooses itself\n\nAvoid tying the metrics to compensation, setting arbitrary targets or publishing league tables.\n\nDORA metrics also inform planning and budgeting conversations, such as those in [software development cost estimation](https://www.desaiinfo.net/software-development/software-development-cost-estimation). If you use Azure DevOps, see [Azure DevOps best practices](https://www.desaiinfo.net/azure-consulting/azure-devops-best-practices) for making deployment data easy to collect. For help establishing a baseline and an improvement plan, [contact us](https://www.desaiinfo.net/contact)."
}