DORA and SPACE Metrics: Definitions and a Worked Example

Define DORA and SPACE measures with clear events, denominators and limitations. Work through a small delivery dataset and build a measurement contract your team can...

Start with a measurement contract

A dashboard is difficult to trust when “deployment” means a pipeline run to one team and a customer-facing release to another. Before choosing targets, agree what the measures count, who owns the definitions and which decisions they will inform.

DORA describes software-delivery performance. SPACE provides a broader way to reason about developer productivity. They answer related questions, but neither supplies a universal score for an engineer or a complete measure of customer value.

Use this guide to define and calculate the measures. Use developer-experience diagnosis to investigate friction, and the productivity improvement guide to design and evaluate a change.

Use the current DORA definitions

DORA's metrics guide, updated January 5, 2026, describes five measures. Older “four keys” dashboards may use broader recovery terminology and omit deployment rework. Do not silently compare differently defined series.

| Measure | What it describes | | --- | --- | | Change lead time | Elapsed time from a code commit to its production deployment. | | Deployment frequency | How often production deployments occur in a stated period. | | Failed deployment recovery time | Time needed to recover from a failed deployment requiring immediate intervention. | | Change fail rate | The share of deployments that require immediate intervention. | | Deployment rework rate | The share of deployments that are unplanned responses to production incidents. |

The last two are not interchangeable. A failed release belongs in the failure numerator. An unplanned corrective deployment belongs in the rework numerator. The same deployment could qualify for both if the attempted fix also fails.

Historical performance clusters describe the research sample and definitions in a particular report. They are not timeless pass/fail thresholds. Compare your service with its own baseline before using external benchmarks, and retain the report year whenever you do use them.

Decide what your instrumentation records

For each service, define a production deployment event with a stable ID, environment, artifact version, completion time and included changes. Deduplicate job retries and individual replica updates when they are part of one rollout. Decide whether configuration, infrastructure, feature-flag and model changes belong in the dataset, then make exclusions visible.

A deployment and a feature release can happen at different times. If a flag keeps new behavior hidden after deployment, the time until users receive it is useful but is not the same interval as commit-to-production lead time. Keep both if the distinction matters.

For lead time, retain commit-to-deployment links. A deployment containing several commits yields several change intervals unless you deliberately choose a deployment-level summary. Squash merges, cherry-picks and missing commit mappings can alter the timestamp you observe. Label the convention instead of reporting false precision.

For failure and recovery, record the deployment associated with the problem, failure onset, detection, service restoration and supporting incident evidence. Document how unknown onset times are estimated. Recovery is not necessarily when the ticket closes or the permanent fix ships. An unrelated provider outage belongs in service-reliability analysis, not automatically in failed-deployment recovery.

The metric owner should resolve disputed classifications with development and operations together. Retain the source records so a surprising result can be checked.

Worked example: five deployments, one failed release

The following dataset is fictional and deliberately small. It represents one service over five calendar days. Each deployment contains one newly committed change. Times use UTC; the deployment timestamp is the point at which the rollout is serving production.

| Deploy | Lead time | Classification | | --- | --- | --- | | D1, day 1 | 2 hours | Planned, no immediate intervention | | D2, day 2 | 4 hours | Planned, no immediate intervention | | D3, day 3 | 6 hours | Planned, caused a production failure | | D4, day 3 | 0.5 hours | Unplanned fix for D3, restored service | | D5, day 5 | 10 hours | Planned, no immediate intervention |

D3 begins failing at 11:00. Detection occurs at 11:10. D4 restores the affected service at 11:40, with recovery confirmed by the agreed health checks. For this example, recovery starts at failure onset and ends at restoration.

The calculations are:

• Deployment frequency: five deployments divided by five calendar days is one deployment per day on average. It does not mean a deployment occurred every day.
• Median change lead time: sorted values are 0.5, 2, 4, 6 and 10 hours, so the median is four hours.
• Change fail rate: one failed deployment divided by five deployments is 20%.
• Deployment rework rate: one unplanned incident-response deployment divided by five deployments is 20%.
• Failed deployment recovery time: 11:40 minus 11:00 is 40 minutes. The detection-to-restoration interval is 30 minutes and would answer a different question.

D4 is in the denominator and the rework numerator, but not the failure numerator because it did not fail. With one failure, the recovery statistic is one observation, not a stable trend. With no failures, report no observed recovery sample rather than zero-minute recovery. With no deployments, failure and rework rates have no denominator and should be unavailable, not 0%.

A late incident link can change a prior period's failure rate. Choose whether reports are restated, show when data was refreshed and retain the classification history. A precise percentage based on incomplete incident links can be less useful than a visibly provisional result.

Use SPACE to ask what delivery data misses

The original SPACE paper by Forsgren and colleagues describes five dimensions: satisfaction and well-being, performance, activity, communication and collaboration, and efficiency and flow. It rejects reducing productivity to a single measure.

Choose evidence that helps answer a specific question. Do not turn the five dimensions into a weighted employee score.

| Dimension | Example question for this service | | --- | --- | | Satisfaction | Do people feel able to sustain the current workload? | | Performance | Are customers completing the task the service exists to support? | | Activity | What types of work are consuming capacity, including support and review? | | Collaboration | Where do unclear ownership or handoffs delay decisions? | | Flow | Which waits and interruptions prevent work from reaching a useful result? |

These are proposed questions, not a standardized survey or validated scoring instrument. Activity data can describe workload, but a commit count cannot establish the quality or value of someone's contribution. Mentoring, incident prevention and useful decisions may leave different traces.

Explain who can access survey results, how they will be used and when they will be deleted. Small-team aggregation may still identify a person. Do not promise anonymity that the collection method or sample size cannot provide. Follow your organization's privacy requirements and avoid publishing identifiable free-text feedback.

Turn a signal into a decision

Suppose lead time rises while failure rate stays similar. Investigate the distribution and a few actual changes before buying a delivery platform. The delay might sit before review, in a release queue, in required evidence gathering or in a large migration. Each suggests a different intervention.

A measurement contract can fit on one page:

1. Name the service, decision and accountable definition owner.
2. Record event boundaries, denominator, window and aggregation method.
3. Identify source systems, missing data and known attribution limits.
4. Pair the delivery signal with customer, reliability and team-context evidence.
5. Agree an improvement hypothesis, guardrails and a review date.
6. Record what happened and whether the evidence warrants another change.

Do not optimize one metric by hiding work. Splitting a rollout into artificial deployments can raise frequency without helping customers. Reclassifying hotfixes as planned work can lower rework while leaving the operating problem unchanged. Audit a small set of records when incentives make the numbers consequential.

For help connecting delivery instrumentation to release and recovery practices, Ampity's DevOps and SRE service is the relevant next step. Bring the current definitions and a sample of linked deployment and incident records, not just the dashboard screenshot.