The DevOps performance metrics worth tracking start with the four DORA metrics, but a healthy program pairs them with security signals so you can tell whether shipping faster is quietly increasing risk. Speed metrics alone can look great while vulnerable dependencies pile up and mean-time-to-remediate quietly climbs. This post covers both halves and how to instrument them without drowning in dashboards.
The four metrics everyone should start with
The DORA research program identified four measures that correlate strongly with high-performing engineering organizations. They are the sensible baseline:
- Deployment frequency — how often you ship to production.
- Lead time for changes — the time from a commit merging to that commit running in production.
- Change failure rate — the percentage of deployments that cause a degraded service or need a rollback.
- Time to restore service — how long it takes to recover from a production incident.
The insight that makes these useful is the pairing of throughput (the first two) with stability (the last two). A team optimizing only for deployment frequency can ship constantly while breaking things constantly. A team optimizing only for stability can achieve zero failures by never shipping. You want both to trend in the right direction together.
How to actually measure them
You do not need a heavyweight platform to start. Most of the data already exists in your version control and CI systems.
# Rough lead time for changes: merge timestamp to deploy timestamp
git log --merges --format="%H %cI" main | head -20
Correlate merge commits with your deployment pipeline's records and you have a first-pass lead time. Deployment frequency is a count of successful production pipeline runs per day or week. Change failure rate needs a consistent definition of "failure" (a rollback, a hotfix within an hour, an incident ticket linked to a deploy). Time to restore comes from your incident tooling.
The hard part is not the math, it is consistency. Pick definitions, write them down, and resist the urge to redefine "failure" every time the number looks bad.
Where security metrics belong
DORA measures how fast and how safely you deliver, but not whether what you deliver is secure. That is a separate axis, and it is the one most dashboards ignore. A few signals close the gap:
- Mean time to remediate (MTTR) vulnerabilities — from the moment a vulnerability is disclosed against something you run to the moment it is fixed in production.
- Vulnerability escape rate — how many known-vulnerable dependencies or misconfigurations reach production despite your gates.
- Percentage of builds with a generated software bill of materials.
- Time-to-detect for a newly disclosed CVE affecting your fleet.
MTTR for vulnerabilities is the one to obsess over. Fast deployment frequency is an asset here: teams that deploy many times a day can ship a dependency bump within hours, while teams on a monthly release train carry a known-critical vulnerability for weeks. Your delivery speed and your security posture are linked.
Instrument security into the same pipeline
You already run tests in CI. Add dependency scanning and let it emit the same kind of metric. When an SCA scan runs on every build, you get a continuous time series of how many known-vulnerable packages are entering your artifacts, and you can chart the vulnerability escape rate the same way you chart change failure rate.
# Example pipeline stage that both gates and emits a metric
- name: dependency-scan
run: sca-scan --fail-on critical --report json > scan.json
# ship scan.json counts to your metrics backend
The point is that security data becomes just another performance metric on the same dashboard, so a rising vulnerability backlog gets the same attention as a rising change failure rate.
Anti-patterns to avoid
A few ways these metrics go wrong:
- Vanity dashboards. Tracking forty metrics means acting on none. Start with the four DORA measures plus MTTR-vuln and expand only when you use what you have.
- Weaponizing metrics against individuals. DORA metrics describe systems, not people. The moment they become a stick, engineers game them.
- Comparing across unlike teams. A platform team and a customer-facing product team have different risk profiles. Compare a team against its own trend, not against others.
Tie metrics back to decisions
A metric that never changes a decision is decoration. For each one, name the action a bad reading should trigger. Change failure rate climbing? Invest in test coverage and progressive delivery. MTTR-vuln climbing? Automate dependency upgrades and add a fast-track path for security patches. If your team is early in this journey, the delivery-and-security fundamentals in the Safeguard Academy help set shared definitions before you start arguing about numbers.
FAQ
What are the four DORA metrics?
Deployment frequency, lead time for changes, change failure rate, and time to restore service. Together they balance delivery throughput against stability, which is why they correlate with high-performing teams.
Are DORA metrics enough on their own?
They measure delivery speed and stability but say nothing about whether what you ship is secure. Pair them with security signals like mean time to remediate vulnerabilities and vulnerability escape rate for a fuller picture.
What is a good deployment frequency?
There is no universal target. Elite teams deploy on demand, often multiple times a day, but the honest goal is your own trend moving up while change failure rate stays flat or falls. Frequency without stability is not progress.
How do I measure mean time to remediate vulnerabilities?
Record when a vulnerability is first detected against something you run, then when the fix reaches production, and average the gap. Continuous dependency scanning gives you the detection timestamp automatically.