Measuring delivery

QuickCart doesn’t need opinions. It needs those four numbers.

The DORA metrics are four numbers that together describe how well a team delivers software. Two measure speed. Two measure stability.

Why all four, and never just one

Any one number on its own can be made to look good in a harmful way:

Watched together, the only reliable way to improve all four is the one the previous lesson showed: smaller batches, with automated testing and deployment. A small change is quick to ship, rarely breaks things, and is easy to undo when it does.

What good looks like

Past DORA reports sorted teams into groups. The boundaries change from year to year, so treat these as rough:

The point isn’t to hit a group’s numbers. It’s to know where you are, and to see whether a change you make, like adding automated tests, moves all four the right way.

Two rules for using them

• They describe a team’s system, not a person. Rank people by them and people will game them: split one change into ten tiny deploys, and frequency looks wonderful while nothing gets better.
• Measure from what your tools already record. Your git history, your deploy logs and your incident records hold most of it. The lab shows how far plain git gets you.

Change how many changes go out in each release, and watch all four numbers. The squares are the changes in one release; red ones are bad changes hiding among the rest.

What to notice: all four numbers get worse together as the batch grows. There’s no setting where you trade a little speed for a lot of stability. Big batches make you slower and more fragile.

Free — you only read your own project’s history.

You’ll measure deployment frequency, lead time, change failure rate and time to restore for a real project, using only git. About 20 minutes.

You need a git project that deploys from its main branch, where each merge to main goes to production. Most web and backend projects work like this. If your project’s main branch is called something else, such as master, use that name wherever you see main. Open the terminal in the project’s folder.

The example output below comes from QuickCart’s order service. Yours will show your own history.

1. List what reached main in the last 30 days

   TerminalCopy

   git log --first-parent --since="30 days ago" --format="%h  %ad  %s" --date=iso main

   Part	What it means
   git log	list commits, newest first
   --first-parent	only the commits made on main, such as merges, not every commit inside each branch that was merged
   --since="30 days ago"	only the last 30 days
   --format="%h %ad %s"	each line shows the short ID, the date and the message
   --date=iso	dates with the time of day, like 2026-09-16 10:45:00 +0000
   main	the branch to read

   You should see

   c14440c  2026-09-22 15:30:00 +0000  Merge pull request #45 from eta
   dc69072  2026-09-16 10:45:00 +0000  Merge pull request #44 from promo2
   9c91e1d  2026-09-09 18:02:00 +0000  Merge pull request #43 from fix-total
   6bb6f9d  2026-09-09 16:20:00 +0000  Merge pull request #42 from promo
   15374d9  2026-09-03 11:05:00 +0000  Merge pull request #41 from menu-photos

   Each line is one change reaching main, so, in a project that deploys every merge, one deployment. Keep this list open; the later steps use its times.

2. Count them: deployment frequency

   TerminalCopy

   git rev-list --count --first-parent --since="30 days ago" main

   Part	What it means
   git rev-list	list commit IDs, with no other detail
   --count	print only how many there are
   --first-parent --since="30 days ago"	the same commits as the last step
   main	the branch to count

   You should see

   5

   QuickCart deployed 5 times in 30 days: a little more than once a week. That’s its deployment frequency.

3. Measure one change: lead time

   Pick a merge from your list. Put its ID in place of the highlighted one in both places, and list the commits it brought in:

   TerminalCopy

   git log --reverse --format="%h  %ad  %s" --date=iso "dc69072^1..dc69072^2"

   Part	What it means
   git log --reverse	list commits, oldest first
   --format="%h %ad %s" --date=iso	ID, date with time, and message
   dc69072^1	the merge’s first parent: what main looked like just before the merge
   dc69072^2	its second parent: the tip of the branch that was merged in
   A..B	commits reachable from B but not from A. Here: exactly the commits the branch added
   the quotes	stop the terminal treating ^ as a special character

   You should see

   e1159a2  2026-09-14 09:00:00 +0000  Promo codes at checkout, with tests for totals
   dea5847  2026-09-15 14:10:00 +0000  Handle expired codes

   The first commit was on 14 September at 09:00. From step 1, the merge was on 16 September at 10:45. So this change’s lead time was about 2 days and 2 hours, plus however long your deploy takes after a merge. Do the same for three or four merges and take the typical value.

4. Find the failures: change failure rate

   Look for changes that undid or patched an earlier one:

   TerminalCopy

   git log --since="30 days ago" --format="%h  %ad  %s" --date=iso -i --grep="revert" --grep="hotfix" main

   Part	What it means
   git log --since="30 days ago"	commits from the last 30 days. No --first-parent this time, so commits inside merged branches are included
   --format="%h %ad %s" --date=iso	ID, date with time, and message
   -i	ignore upper and lower case
   --grep="revert" --grep="hotfix"	messages containing either word
   main	the branch to read

   You should see

   a8bbe85  2026-09-09 17:05:00 +0000  Revert promo codes: totals wrong for some orders

   One of QuickCart’s 5 deployments, the promo codes in #42, had to be undone. Its change failure rate is 1 ÷ 5 = 20%.

   Git only knows about failures someone fixed with a commit. If your team keeps incident records, count from those instead; they’re more complete.

5. Time the recovery: time to restore

   For each failure, find when the bad change went out and when the fix went out, both in the step 1 list:

   Event	From the list	Time
   The bad change is deployed	6bb6f9d Merge pull request #42 from promo	16:20
   The fix is deployed	9c91e1d Merge pull request #43 from fix-total	18:02

   QuickCart’s time to restore was 1 hour 42 minutes. Strictly, the clock starts when users were first affected, which your monitoring knows better than git. The deploy time is a good first estimate.

6. Write down your four numbers

   Metric	QuickCart	Yours
   Deployment frequency	5 in 30 days
   Lead time for changes	About 2 days
   Change failure rate	20%
   Time to restore	About 2 hours

   You should see

   Four numbers for your project. Look at the one that’s furthest from the strongest teams in the idea. Measure again in a month to see if it moved.

7. Clean-up step: Clean up

   Nothing to delete. Every command here only reads git history.