Deployment frequency and lead time — the first pair of DORA metrics and what they mean

DORA identified four metrics that predict software delivery performance: deployment frequency, lead time for changes, change failure rate, and time to restore service. The first two are the throughput metrics: how often does the team ship, and how fast does a commit become a deploy. The second two are the stability metrics: how often do the deploys fail, and how fast does the team recover. This lesson covers the first pair.

Deployment frequency

Deployment frequency is the rate at which a team deploys code to production. For an infrastructure team, the definition extends to configuration changes, Terraform applies, and policy updates - any production change that goes through the CI/CD pipeline counts.

The metric is computed from the run history: count the runs in a window whose job is a deploy job and whose conclusion is success:

OWNER=acme
REPO=platform
gh api repos/$OWNER/$REPO/actions/runs \
  --jq '[.workflow_runs[] | select(.name == "deploy-production" and .conclusion == "success")] | length'
# returns: count of successful production deploys in the API window

The DORA performance bands for deployment frequency (as published in the DORA State of DevOps reports):

• Elite: On-demand (multiple deploys per day).
• High: Between once per day and once per week.
• Medium: Between once per week and once per month.
• Low: Between once per month and once per six months.

For an infrastructure team, “elite” is rarely the right target. A team that deploys Terraform state changes multiple times per day is a team that is changing production constantly; the risk profile depends on what is being changed. The right target is the band that matches the team’s change volume and risk tolerance.

flowchart TB
    A["Deployment frequency"] --> B["Elite\non-demand"]
    A --> C["High\ndaily to weekly"]
    A --> D["Medium\nweekly to monthly"]
    A --> E["Low\nmonthly to half-yearly"]
    A --> F["Bottleneck\nless than half-yearly"]

Lead time for changes

Lead time for changes is the duration from the first commit to the successful production deploy. For an infrastructure team, the first commit is the commit that introduces the change; the production deploy is the workflow run that applies the change to production.

The metric is computed from two data points: the commit timestamp (git log -1 --format=%cI) and the deploy run timestamp (run_started_at or updated_at). The lead time is the delta:

COMMIT_TS="2026-08-15T10:00:00Z"
DEPLOY_TS=$(gh api repos/$OWNER/$REPO/actions/runs/$RUN_ID \
  --jq '.updated_at')
# lead time in hours = (DEPLOY_TS - COMMIT_TS) / 3600

The DORA performance bands for lead time:

• Elite: Less than one hour.
• High: Between one day and one week.
• Medium: Between one week and one month.
• Low: Between one month and six months.

For an infrastructure team, lead time includes the review time, the test time, the approval time, and the deploy queue time. A team with a lead time of one week is a team where the median commit waits one week to reach production; the cause is usually review backlog, test queue, or deploy serialisation.

The operational meaning

The two metrics together answer the question “how fast does this team ship?”. The four quadrants:

The diagnostic value is in the asymmetry. A team with high frequency and high lead time is a team that has removed the deploy friction but not the upstream friction. The fix is to address the upstream bottleneck (review backlog, test queue, approval gates). A team with low frequency and low lead time is a team that has removed the deploy friction but chosen not to ship. The fix is a policy discussion about batching.

Computing both metrics in practice

A useful operational query extracts both metrics for a window:

OWNER=acme
REPO=platform
gh api repos/$OWNER/$REPO/actions/runs \
  --jq '.workflow_runs | map({
    id: .id,
    name: .name,
    conclusion: .conclusion,
    head_sha: .head_sha,
    created_at: .created_at,
    updated_at: .updated_at
  }) | {deploys: map(select(.name == "deploy-production" and .conclusion == "success")) | length, total: length}'
# returns: deploy count and total run count for the API window

The lead time requires pairing each deploy with its commit timestamp. The head_sha field links the run to the commit; the commit timestamp is fetched with git show:

# for a specific deploy run, get the lead time
RUN_ID=12345
HEAD_SHA=$(gh api repos/$OWNER/$REPO/actions/runs/$RUN_ID --jq '.head_sha')
COMMIT_TS=$(git show -s --format=%cI $HEAD_SHA)
DEPLOY_TS=$(gh api repos/$OWNER/$REPO/actions/runs/$RUN_ID --jq '.updated_at')
# lead_time_hours = (DEPLOY_TS - COMMIT_TS) / 3600

The team that runs this query weekly and tracks both metrics has a deployment-frequency-and-lead-time dashboard. The dashboard answers the question “are we getting faster?” with data, not with intuition.

Production discipline

1. Track both metrics, not just one. Frequency and lead time answer different questions; the pair is the picture.
2. Use the DORA bands as diagnostic input, not as targets. The goal is to remove friction; the band is the result.
3. Diagnose the asymmetric quadrants. High frequency with high lead time points to upstream friction; low frequency with low lead time points to a batching policy.
4. Pair the metrics with the change content. A team that deploys often is not necessarily a team that ships value; the value is in the change.
5. Avoid gaming the metric. A team that splits one deploy into many to inflate frequency is a team that has lost sight of what the metric is for.

Cross-course references

• Observability course - Part II (SLOs) covers the distinction between throughput metrics and latency metrics; deployment frequency is throughput, lead time is latency.
• This course, Part LIX (Rollback) and Part LX (Decision) cover the rollback discipline that becomes necessary when lead time is high and changes are large.
• This course, Part LXII-04 (Throttling) covers the queue-management discipline that affects lead time.

Quiz