Computing DORA Metrics From Your Own Git History

Four numbers, one git log, no dashboard.

A repo with a deploy history

Four commits and four annotated deploy tags, one of them marked failed, built with explicit timestamps so the metrics below come out to round numbers:

# .scratch/build_dora_repo.py (excerpt)
commit("feature A: add checkout retry", "2026-01-01T09:00:00")
tag("v1", "deploy v1", "2026-01-02T09:00:00", failed=False)

commit("feature B: new pricing table", "2026-01-03T09:00:00")
tag("v2", "deploy v2", "2026-01-04T09:00:00", failed=True)

commit("hotfix: revert pricing table bug", "2026-01-04T15:00:00")
tag("v3", "deploy v3", "2026-01-04T18:00:00", failed=False)

commit("feature C: add search filters", "2026-01-06T09:00:00")
tag("v4", "deploy v4", "2026-01-07T09:00:00", failed=False)

Each deploy is a real annotated tag with a [status:success] or [status:FAILED] marker in its message — a convention, not a git feature, but enough for a script to parse:

$ git for-each-ref --format='%(refname:short) %(creatordate:iso-strict) %(contents:subject)' refs/tags
v1 2026-01-02T09:00:00+05:30 deploy v1 [status:success]
v2 2026-01-04T09:00:00+05:30 deploy v2 [status:FAILED]
v3 2026-01-04T18:00:00+05:30 deploy v3 [status:success]
v4 2026-01-07T09:00:00+05:30 deploy v4 [status:success]

Deployment frequency

Deploys per week, from the span between the first and last deploy tag:

# .scratch/compute_dora.py (excerpt)
span_days = (tags[-1][1] - tags[0][1]).total_seconds() / 86400
deploys_per_week = len(tags) / span_days * 7
print(f"Deployment frequency: {len(tags)} deploys over {span_days:.1f} days = {deploys_per_week:.2f}/week")

Deployment frequency: 4 deploys over 5.0 days = 5.60/week

Lead time for changes

For each deploy, find the earliest commit made since the previous deploy, and measure how long it waited before shipping:

lead_times = []
prev_deploy_time = commits[0][1]
for name, deploy_time, _ in tags:
    new_commits = [c for c in commits if prev_deploy_time <= c[1] < deploy_time or c[1] == prev_deploy_time]
    first_new = min((c[1] for c in new_commits), default=deploy_time)
    lead_hours = (deploy_time - first_new).total_seconds() / 3600
    lead_times.append(lead_hours)
    prev_deploy_time = deploy_time

Lead time for changes: ['24.0h', '24.0h', '3.0h', '24.0h'] -> avg 18.75h

The 3-hour outlier is the hotfix — committed at 15:00 and deployed at 18:00 the same day, dragging the average down from what three ordinary 24-hour cycles alone would show. Lead time is sensitive to exactly this kind of urgent, fast-tracked change, which is part of why it’s tracked as an average rather than read from any single deploy.

Change failure rate

A direct read of the [status:FAILED] markers:

failed = [t for t in tags if t[2]]
print(f"Change failure rate: {len(failed)}/{len(tags)} = {len(failed) / len(tags):.1%}")

Change failure rate: 1/4 = 25.0%

MTTR

For each failed deploy, the gap until the next deploy — the point at which the failure was actually resolved in production:

restore_times = []
for i, (name, deploy_time, is_failed) in enumerate(tags):
    if is_failed and i + 1 < len(tags):
        restore_hours = (tags[i + 1][1] - deploy_time).total_seconds() / 3600
        restore_times.append(restore_hours)

MTTR: ['9.0h'] -> avg 9.00h

v2 deployed at 09:00 and broke pricing; v3 — the hotfix deploy — landed at 18:00 the same day. Nine hours from a failed deploy to its fix is the entire MTTR calculation, read straight off two tag timestamps.

What the numbers say together

None of these numbers means anything alone — a 25% failure rate next to a 9-hour MTTR reads very differently than the same 25% next to a 9-day MTTR. DORA’s own research groups performance by combinations of all four, not any single metric in isolation.

Practice