DORA Metrics: The Four Keys Explained

By Kokil Thapa | Last reviewed: September 2026

DORA Metrics: The Four Keys Explained starts with a simple idea. High-performing teams ship small changes often, recover fast when something breaks, and keep failure rates low. The DevOps Research and Assessment (DORA) program, now published at dora.dev, distilled years of survey data into four metrics that predict delivery performance better than vanity counts like lines of code or story points. If you run a custom software team, a law-firm portal, or a Laravel eCommerce build, these four numbers tell you whether your pipeline actually works — or just looks busy on a Monday stand-up.

What Are DORA Metrics and the Four Keys?

DORA metrics measure software delivery performance through four correlated signals. They do not replace the four golden signals of monitoring, but they answer a different question. Golden signals watch runtime health. DORA keys watch how your team turns commits into production value.

The four keys are:

• Deployment frequency — how often code reaches production
• Lead time for changes — time from commit to production
• Change failure rate — share of deployments that cause failure
• Mean time to restore (MTTR) — time to recover from production failure

Google's research groups teams into performance tiers: Elite, High, Medium, and Low. Elite teams deploy multiple times per day. Low performers may deploy monthly or less. The gap is not about headcount. It is about automation, batch size, and feedback loops.

Think of them as a balanced scorecard. Chasing deployment frequency alone invites chaos. Ignoring lead time hides a two-week QA bottleneck. A team that deploys daily but breaks production weekly is not elite — it is firefighting on a schedule.

In my experience working on production Laravel applications, teams that track all four keys spot problems earlier. A rising change failure rate often precedes a client escalation by days. That is cheaper than debugging under pressure at 11 p.m.

How Do You Measure Deployment Frequency and Lead Time for Changes?

Deployment frequency counts successful production releases over a period. Lead time measures elapsed time from the first commit in a change set to that change running in production. Both need a clear definition of "deployment" and "production."

Define your deployment event

A deployment is not a git push. It is the moment production traffic serves the new release. On a Deployer 7 symlink swap, that is when current points to the new release and PHP-FPM reloads. On WordPress, it might be a theme or plugin update pushed through CI. Write the definition down. Mixed definitions destroy trend lines.

Instrument from your pipeline

Most teams pull these numbers from CI/CD and Git history. GitLab CI, GitHub Actions, and Deployer hooks all emit timestamps you can aggregate. You do not need a commercial platform on day one. A spreadsheet fed by pipeline webhooks works for a five-person team.

Example GitLab CI job that records deployment metadata:

deploy_production:
  stage: deploy
  script:
    - dep deploy production -vvv
    - |
      curl -X POST "$METRICS_WEBHOOK" \
        -H "Content-Type: application/json" \
        -d "{
          \"event\": \"deployment\",
          \"environment\": \"production\",
          \"commit_sha\": \"$CI_COMMIT_SHA\",
          \"commit_time\": \"$CI_COMMIT_TIMESTAMP\",
          \"deployed_at\": \"$(date -u +%Y-%m-%dT%H:%M:%SZ)\",
          \"project\": \"$CI_PROJECT_NAME\"
        }"
  only:
    - main

Your webhook receiver stores the row. Lead time is deployed_at minus commit_time for the deployed SHA. Deployment frequency is a count grouped by day or week.

Split lead time into phases

Raw lead time hides where work stalls. Break it into coding, review, CI, and deploy phases. A common pattern I've seen repeatedly: coding takes two hours, review takes four days. Fixing review latency beats buying another server.

For deeper runtime correlation, pair DORA data with Prometheus metrics fundamentals and your application logs. A deploy timestamp overlay on error-rate graphs makes change failure obvious within minutes.

What Is a Good Change Failure Rate and MTTR Benchmark?

Change failure rate is the percentage of production deployments that cause a degradation. That includes rollbacks, hotfixes, or incidents tied to a specific release. MTTR is the average time from detecting a production incident to restoring normal service.

DORA publishes tier benchmarks annually in the State of DevOps report. Numbers shift slightly each year, but the shape holds. Elite teams fail less than 15% of changes and restore service in under one hour.

Do not treat these as HR scorecards. They are diagnostic. A Medium team shipping twice a week with 20% failure rate has a quality problem, not a speed problem. Fix tests and staging parity before pushing for daily deploys.

How to calculate change failure rate

Use a consistent incident tag in your tracker. When post-mortem links to commit SHA abc123, mark that deployment as failed. Formula:

change_failure_rate = (failed_deployments / total_deployments) * 100

Count only production deployments in the denominator. Staging failures matter for team learning but do not belong in this metric.

How to calculate MTTR

Record incident_detected_at and incident_resolved_at. Resolved means users can complete core workflows again — not merely that the on-call engineer went back to bed.

MTTR = sum(resolved_at - detected_at) / incident_count

On sister sites I maintain with Deployer 7 and GitLab CI, rollback via dep rollback often cuts MTTR below fifteen minutes. That only works when you deploy small changes and keep the previous release intact.

Link incident records to deploy events. Without that link, change failure rate becomes guesswork and MTTR improvements look cosmetic.

How Do You Implement DORA Metrics in a Laravel or PHP Team?

PHP teams — Laravel 12 or 13 on PHP 8.3+, WordPress 7.1, or Magento 2.4.x — face the same measurement problem as any stack. The tooling differs. The events do not.

Step 1: Standardise your deploy path

One path to production. No manual FTP uploads mixed with CI deploys. On a real client project, I standardised Deployer 7 across legal-tech portals sharing EC2 infrastructure. Once every site used the same pipeline shape, cross-project comparison became meaningful.

1. Pick one branch as production (usually main)
2. Run tests in CI before deploy
3. Tag each release with commit SHA in a deployments table or log file
4. Reload PHP-FPM after symlink swap to clear opcache
5. Record deploy timestamp in your metrics store

Step 2: Store events in a simple schema

CREATE TABLE deployments (
  id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  project VARCHAR(100) NOT NULL,
  environment VARCHAR(50) NOT NULL,
  commit_sha CHAR(40) NOT NULL,
  commit_at DATETIME NOT NULL,
  deployed_at DATETIME NOT NULL,
  lead_time_seconds INT GENERATED ALWAYS AS (
    TIMESTAMPDIFF(SECOND, commit_at, deployed_at)
  ) STORED,
  failed TINYINT(1) DEFAULT 0,
  incident_id BIGINT UNSIGNED NULL,
  INDEX idx_deployed_at (deployed_at),
  INDEX idx_project_env (project, environment)
);

MySQL 9.7 or MariaDB 12.3 both handle this fine. For aggregation dashboards, a nightly cron job or Laravel scheduled command can compute weekly rollups.

Step 3: Wire CI and incident tracking

Mark a deployment failed when any of these occur within a defined window (often 24 hours):

• Automated rollback executed
• Incident ticket tagged with the deploy SHA
• Hotfix branch merged directly to production

Integrate with your existing observability stack. If you already collect metrics, logs, and traces, add deploy annotations. Grafana and similar tools can draw vertical lines at deploy time.

Step 4: Review weekly, act monthly

Weekly reviews keep the team honest. Monthly reviews drive process changes. A rising lead time with flat deployment frequency usually means reviews or QA are the bottleneck. Pair these reviews with testing and optimization practices rather than blame.

For JSON pipeline payloads during setup, a quick pass through the JSON formatter tool catches malformed webhook bodies before they silently fail in production.

How Do DORA Metrics Compare to Other Engineering Metrics?

DORA keys are not the only numbers worth tracking. They complement — not replace — product, quality, and developer-experience metrics. The mistake is mixing them into one dashboard without context.

On booking platforms like Adventure Third Pole Trek, delivery metrics matter because seasonal demand spikes punish slow releases. A feature held back two weeks may miss the booking window entirely. DORA numbers translate directly into business risk there.

Similarly, a legal-tech portal needs low change failure rate. A broken form during peak inquiry hours costs leads, not just uptime percentage. MTTR matters because lawyers and clients expect the site to work when they submit documents.

Compare DORA with AI code review in CI. AI review can shrink review-phase lead time. It can also increase noise if not tuned. Measure before and after. That is the whole point of having baselines.

For infrastructure-heavy work, pair DORA tracking with solid Linux administration practices and support and maintenance contracts. Metrics without someone acting on them become wallpaper.

Security-minded teams sometimes worry that faster deploys mean riskier deploys. The research shows the opposite when batch sizes shrink and automation improves. Read the Accelerate book for the original evidence base. The four keys emerged from that multi-year study, not from a vendor checklist.

What Mistakes Do Teams Make When Adopting DORA Metrics?

Adoption fails for predictable reasons. Most are process problems dressed as tooling problems.

• Gaming the metric — deploying README-only changes to inflate frequency
• Skipping failure linkage — counting deploys but not tagging incidents to SHAs
• Weekly batch releases — calling it "continuous" because CI exists
• Individual scorecards — DORA is a system metric, not a performance review input
• No baseline period — changing three variables at once and claiming victory

A pattern I've seen repeatedly on production deployments: the pipeline works locally but fails after deploy due to opcache, permissions, or stale cron paths. Those incidents inflate change failure rate until the root cause is fixed once. Track the metric, fix the pipeline, then re-measure.

If you are modernising a legacy PHP app, start with weekly deploys and automated smoke tests. Jumping to multiple daily releases before tests exist will raise failure rate faster than it raises frequency. Incremental improvement matches how most Nepal-based teams actually operate — small staff, real clients, limited budget.

For enterprise-scale systems, see how enterprise application development approaches phased rollouts. Blue-green or canary deploys improve MTTR and failure containment without hiding poor test coverage.

CI/CD hardening guides like GitHub Actions deploy with OIDC reduce credential-related deploy failures. That is a legitimate MTTR and change failure win, not a side project.

Key Takeaways

• Track all four DORA keys together — deployment frequency, lead time, change failure rate, and MTTR — not one in isolation.
• Define "deployment" and "production failure" in writing before you collect data.
• Instrument your existing CI/CD pipeline with webhook events rather than buying a platform on day one.
• Split lead time into review, CI, and deploy phases to find the real bottleneck.
• Link incident tickets to commit SHAs so change failure rate reflects reality.
• Review trends weekly and change process monthly; use benchmarks as diagnostics, not punishment.

People Also Ask

What are the four DORA metrics?

The four DORA metrics are deployment frequency, lead time for changes, change failure rate, and mean time to restore (MTTR). They measure how often you deploy, how fast changes reach production, how often deployments fail, and how quickly you recover from incidents.

What is a good deployment frequency?

Elite performers deploy on demand, often multiple times per day. High performers deploy between once per day and once per week. Context matters — a stable brochure site may legitimately deploy weekly while a SaaS product targets daily releases.

How is lead time for changes different from cycle time?

Lead time for changes starts at first commit and ends when code runs in production. Cycle time often starts when work enters an active sprint board. DORA lead time includes review and CI wait time, which board metrics frequently hide.

Do DORA metrics work for small teams?

Yes. Small teams benefit because the metrics expose bottlenecks early. A five-person Laravel shop can track deployments in a single database table and review numbers in a weekly fifteen-minute meeting without enterprise tooling.

Start Measuring What Actually Matters

DORA Metrics: The Four Keys Explained is not theory for Silicon Valley unicorns. It is a practical lens for any team that ships code to production — including Laravel booking systems, WooCommerce stores, and legal portals under real client pressure. Start with one project, log ten deployments, link your next incident to a SHA, and you will already know more than most teams guessing from gut feel.

If you want help wiring CI/CD, deploy automation, or observability into an existing PHP application, see web development services or reach out via contact us. You can also browse the portfolio for production examples or read more from about me on how these pipelines run on live client infrastructure.