Spend the first 30 days measuring, not improving. Pick one service, write definitions in week one, collect delivery and security data in weeks two and three, and review it with the team in week four. Set no targets yet. DORA's guide itself suggests that conversations can come before complex integrations.
Why baseline first
DORA's guide cautions against setting metrics as goals, and says building complex integrations may not be worth the upfront investment. A plain baseline avoids both mistakes. You learn what is true before you decide what to change.
Week 1: definitions and scope
- Choose one service with an engaged team. DORA says the metrics fit one application or service at a time.
- Write definitions for the five delivery metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate.
- Write definitions for three security measures: time to remediate by severity, scan coverage, and gate overrides.
- Decide what counts as immediate intervention and as unplanned.
- Tell the team what the numbers are for, and what they are not for.
Week 2: collect delivery data
- Export deployments for the last 90 days from your pipeline or release tooling.
- Link each to the first commit in it, to compute lead time.
- List rollbacks and hotfixes from incident tickets, with dates and causes.
Expect gaps. If data is missing, note it. A baseline with honest gaps is more useful than a neat one built on guesses.
Week 3: collect security data
- Export findings with identified and fixed dates, severity and service.
- Count repos and images on the service, and how many were scanned.
- Pull the override or bypass log for your gate, if you have one.
Week 4: review together
| Question | Why ask it |
|---|---|
| Do the numbers match how the team feels? | Mismatches reveal definition problems |
| Where is the biggest wait in lead time? | Points to the first fix |
| How many rollbacks had a security cause? | Starts the tagging habit |
| Which severity ages worst? | Chooses a remediation focus |
| What is unmeasured? | Lists the data gaps |
Write down three observations and one experiment for the next month. Keep the experiment small.
Pitfalls
- Choosing too many services and finishing none.
- Using averages for lead time. Show median and a high percentile.
- Hiding poor data quality. Note it on the page.
- Sharing team numbers with other teams in a ranking.
What to do next
After the baseline, add a tagging habit for unplanned deployments, then pick one measure to improve for one quarter. Revisit scope after that.
Quick check
What if we do not track deployments at all?
Start by recording them by hand in a shared log for a month. Imperfect data is a start.
Do we need a dashboard tool?
Not for a baseline. A spreadsheet is enough. Automate later.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at the inventory a scan produces. It gives you the coverage denominator for week three.
How Safeguard fits
Safeguard offers asset discovery, dependency scanning and a free scan at gold.safeguard.sh/scan, which can supply the starting security data.
Sources
- DORA, DORA's software delivery performance metrics: https://dora.dev/guides/dora-metrics/
Last reviewed: 19 October 2026.
