Measuring DevOps Performance: DORA Metrics, Flow and Honest Dashboards

A story to begin with

The four key metrics

Large, multi-year research programmes on software delivery repeatedly found that four measures separate high-performing teams from others. Two measure speed, two measure stability.

flowchart LR
  subgraph Speed
    DF[Deployment frequency<br/>how often do we release?]
    LT[Lead time for changes<br/>commit to production]
  end
  subgraph Stability
    CFR[Change failure rate<br/>how many releases cause trouble?]
    TTR[Time to restore<br/>how fast do we recover?]
  end
  Speed --> O[Better business outcomes]
  Stability --> O
  style O fill:#34d399,color:#062

Many teams add a fifth measure, reliability (are we meeting our SLOs?), which connects delivery to the user experience.

Performance bands (rough guide)

Treat bands as direction, not a league table: compare yourself with your past self.

Getting the data without a big project

You probably already have the raw data.

flowchart LR
  G[Git: commits and merge times] --> C
  CI[CI/CD: pipeline runs and deploy events] --> C
  I[Incident tool: start, resolve times, linked deploys] --> C
  C[Small script or dashboard] --> M[DORA dashboard per team]
  style C fill:#6366f1,color:#fff

• Deployment frequency: count successful pipeline runs that deploy to production (or deploy events from your delivery tool).
• Lead time: for each deploy, find the commits it contained and subtract the first commit or merge time from the deploy time.
• Change failure rate: label incidents or rollbacks with the deploy that caused them; divide by deploys.
• Time to restore: from your incident tool: detection or start time to resolution.

# Tiny example: median lead time from a list of (commit_time, deploy_time) pairs
from statistics import median
from datetime import datetime

pairs = [("2026-05-01T09:00", "2026-05-03T14:00"), ("2026-05-02T11:30", "2026-05-03T14:00")]
hours = [(datetime.fromisoformat(d) - datetime.fromisoformat(c)).total_seconds() / 3600 for c, d in pairs]
print(f"median lead time: {median(hours):.1f} hours")

Start with a spreadsheet or a simple script, agree definitions, and only then buy or build tooling. Agree precisely what counts as a deployment, a failure and "production".

Supporting measures

Using metrics well

Metrics change behaviour, so use them carefully.

Do:

• Measure the team and system, never rank individuals.
• Look at trends over months, not daily noise.
• Show all four metrics together; improving one while another collapses is a warning.
• Use them to start conversations ("why did lead time double?") rather than to judge.
• Make dashboards visible to the teams they describe.

Do not:

• Set targets such as "deploy twice as often" without fixing the causes; people will game the number (split deployments, relabel failures).
• Use metrics as inputs to performance reviews or bonuses.
• Compare unlike teams (a mobile app versus a payment core).
• Collect more than you will act on.

flowchart TD
  A[Metric moves] --> B{Why?}
  B --> C[Look at the flow:<br/>where is time spent?]
  C --> D[Form a hypothesis]
  D --> E[Small experiment]
  E --> F[Did the metric and<br/>the underlying work improve?]
  style B fill:#6366f1,color:#fff

Reading the numbers: common patterns

Rolling out measurement in your organisation

1. Pick two or three pilot teams that are willing and have different shapes of work.
2. Agree definitions in one page: what is a deployment, a failure, a restore, and where the data comes from.
3. Collect a baseline for the last three to six months, manually if needed.
4. Build a simple shared dashboard and review it for 15 minutes in a regular team ritual.
5. Choose one improvement per quarter per team, based on its weakest metric.
6. Share learnings across teams in a monthly session; celebrate improvement, not absolute numbers.
7. Keep leaders aligned: report trends and the improvements behind them, not rankings.
8. Revisit definitions yearly as tools and practices evolve.

Pitfalls

• Debating definitions for months before measuring anything.
• Using the numbers to punish, so people stop being honest.
• Measuring only speed.
• A dashboard nobody uses in a decision.

Interview questions

Q1. What are the four key DevOps metrics? Deployment frequency, lead time for changes, change failure rate and time to restore service. The first two measure speed; the last two measure stability.

Q2. How would you measure lead time? For each production deployment, find the commits it contains and compute the time from the first commit (or merge) to the deployment, then use the median across deployments.

Q3. What happens if you target the metrics directly? People can game them (for example splitting releases to inflate frequency or relabelling failures). Use metrics to understand and improve the system, and look at them together.

Q4. A team deploys daily but has a 35% change failure rate. What do you do? Investigate failure causes, strengthen automated tests and review, add canary releases and faster rollback, and make changes smaller so failures are easier to isolate.

Q5. Why should metrics never be used for individual performance reviews? Delivery results come from the system and the team; using them to judge individuals encourages gaming, blame and hiding of failures, which destroys the learning culture the metrics are meant to support.

Next: Misconceptions and Anti-Patterns covers what quietly stops improvement.