DORA

As explained in Effective Platform Engineering

The DORA framework is a software delivery performance framework centered on deployment frequency, lead time for changes, change failure rate, and time to restore service.

DORA is a software delivery performance framework built around deployment frequency, lead time for changes, change failure rate, and time to restore service. Together, these measures show how quickly and reliably teams deliver changes and recover from failures. section 3.4.3 section 10.1.2

Use the four metrics to connect delivery performance with operational outcomes:

• Deployment frequency measures how often successful changes reach production; interpret it alongside the platform capabilities that can actually influence delivery. section 3.4.3 section 10.1.2
• Lead time for changes measures elapsed time from code commit or story pickup to production, revealing delays in build, test, approval, or dependency planning. section 3.4.3 section 10.1.2
• Change failure rate measures the proportion of production deployments that fail, linking delivery speed to reliability, downtime, and user trust. section 10.1.2
• Time to restore service measures recovery after failure; detection and notification time are important parts of understanding recovery performance. section 3.4.3

Treat DORA as a lagging view of delivery outcomes, not as a complete platform scorecard. Pair it with leading indicators such as deployment automation, pipeline-stage duration, code-quality violations, test coverage, manual-test ratios, and developer satisfaction. This combination helps teams identify bottlenecks before they appear in the four headline metrics. section 10.1.1 section 10.1.2

Epetech’s measurement approach

Epetech used the four DORA metrics to track delivery and reliability while examining the underlying causes. It monitored automated-deployment percentages and per-team deployment frequency, broke lead time into build, test, and approval stages, and used quality and testing indicators as early warnings for failed production changes. section 10.1.2

Figure 10.2 Key leading metrics used by Epetech to understand and use the DORA lagging metrics

Use the leading-metrics diagram to trace how automation, pipeline timing, code quality, and testing inform the four DORA outcomes. section 10.1.2

How Effective Platform Engineering covers it

How deep it goes

Defines all four measures and supplements them with leading indicators, while stopping short of prescribing a complete measurement implementation.

Examples

Uses Epetech’s deployment, pipeline-stage, automation, code-quality, and testing indicators as practical measurement examples.

What you can do after

Evaluate delivery performance and diagnose bottlenecks by combining DORA outcomes with leading engineering indicators.

How it connects

Connects platform engineering with developer experience, software delivery, reliability, and business outcomes.

liveBookmanning.com

Read Effective Platform Engineering on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Platform Engineering on KubernetesA DORA metric is a software delivery performance measure from the DORA research program, including delivery speed, throughput, and stability dimensions.
• 

  liveBookmanning.com
  "Looks Good to Me"A software delivery performance measure covering deployment frequency, change lead time, time to restore service, or change failure rate.
• 

  liveBookmanning.com
  Architecture Modernization: Socio-technical alignment of software, strategy, and structureDORA metrics are software delivery performance measures covering deployment frequency, lead time for changes, change failure rate, and time to restore service.

Compare how 4 books explain DORA →

Related concepts

• change failure ratehas part · Change failure rate is the proportion of deployed software changes that cause failures requiring remediation, rollback, recovery, or other corrective action.
• deployment frequencyhas part · Deployment frequency is the rate at which software changes are deployed to a target environment, such as production.
• lead timehas part · Lead time is the elapsed time from the initiation, request, or availability of work until its completion or delivery.
• mean time to resolutionhas part · Mean time to resolution is the average elapsed time from identifying or reporting an issue, failure, or incident until it is resolved or affected service is restored.

This explainer was generated by Manning's knowledge graph from the text of Effective Platform Engineering. The section links point to the parts of the book it draws on.