Worksheet
DORA metrics in 15 minutes
A one-page sheet to measure deployment frequency, lead time, change failure rate, and time to restore from your Git and deploy history.
I'm starting to see AI tools triple the number of pull requests in some teams. Review becomes the bottleneck. The team can't say whether delivery got faster or only busier. The four DORA metrics answer that question. The data already sits in Git and the CI history.
The last column is for your own numbers. Rough numbers work for a first pass. The point is to find the one metric that holds the other three back.
From the talk: Ship fast, break nothing: CI/CD for vibe-coded startups
The four metrics
| Metric | What it measures | How I measure it | Today |
|---|---|---|---|
| Deployment frequency | How often a change reaches production. | The count of successful production deploys in the last 30 days. | |
| Lead time for changes | How long a change takes from first commit to production. | The median time from first commit to the deploy that shipped it, over the last 20 merged pull requests. | |
| Change failure rate | The share of deploys that cause a failure needing a fix. | Deploys followed by a rollback, revert, or hotfix, divided by all deploys in the period. | |
| Time to restore service | How long recovery from a production failure takes. | The median time from first alert to a live fix, over the last few incidents. |
The raw data, from the GitHub CLI
Two commands give most of what the sheet needs. The workflow name ci.yml changes to the name of the deploy workflow.
# Production deploys on main in the last 30 days (successful runs of the deploy workflow).
gh run list --workflow ci.yml --branch main --event push --status success \
--created ">=$(date -d '30 days ago' +%F)" --limit 500 --json createdAt | jq length
# The last 20 merged pull requests, with when they opened and merged.
gh pr list --state merged --limit 20 --json number,createdAt,mergedAtReading the numbers
I read the four together. Frequent deploys with a high failure rate point to thin checks. A long lead time with a low failure rate usually points to big pull requests or slow review. A second measurement a month later, from the same sources, shows whether the trend is real.
What I leave out on purpose
I leave out a metrics platform, a dashboard nobody opens, and per-engineer numbers. The four metrics describe the system, not the people in it. A spreadsheet with a monthly update is enough to start.
Next step
I highly recommend bringing your four numbers to a thirty-minute call. I'll show which one holds the other three back and what I'd change first. Which of the four numbers surprised your team most?
Book a callThese takeaways are an engineer's reading of the rules and the tools. I wrote them to help teams decide what to build. They aren't legal advice. I recommend checking the current text with your own counsel before planning around a date or a threshold.
Other takeaways from this talk
Checklist
The 10-check vibe-coding safety net
Ten yes/no checks that turn a CI pipeline into the reviewer a solo founder or small team doesn't have. About a day of setup.
Template
Starter GitHub Actions workflow
A copy-ready CI workflow: lint, types, tests, build, dependency review, CodeQL, and an OIDC deploy from main with no stored keys.
Policy template
Agent permissions in one page
What an AI coding agent may and may not do in your repository, cloud, and data, with how to enforce each line. Ready to copy into a policy.
Let's talk.
A 30-minute call, no pitch. We look at your current setup, your stage, and the thing that's bothering you about it. I give a straight opinion on what to change, what to leave alone, and whether the problem is the one it looks like. What's the one thing in your stack you'd fix tomorrow?
Prefer email or phone? hello@netninjas.eu or +31 6 45984313