The DevOps success metrics that actually predict delivery health are the four DORA measures, deployment frequency, lead time for changes, change failure rate, and time to restore service, supplemented by a small set of reliability and security signals. Everything else is usually a proxy for activity rather than outcomes, and activity is easy to fake. A team can raise its commit count and lower its pull-request cycle time while shipping the same amount of working software, which is why the metrics below deliberately measure the flow and stability of value to users, not how busy anyone looks.
The trap with DevOps metrics is Goodhart's law: when a measure becomes a target, it stops being a good measure. The defense is to track a balanced set where gaming one number degrades another.
The four DORA metrics
Years of research on high-performing engineering organizations converged on four measures, split into two throughput and two stability metrics. Their power comes from being tracked together, because throughput without stability is recklessness and stability without throughput is stagnation.
- Deployment frequency: how often you ship to production. Elite teams deploy on demand, multiple times per day.
- Lead time for changes: how long from a commit to that commit running in production. Shorter means a tighter feedback loop.
- Change failure rate: the percentage of deployments that cause a failure needing remediation.
- Time to restore service: how long to recover once a failure hits production.
The first two are throughput. The last two are stability. If a team pushes deployment frequency up while change failure rate climbs with it, the metrics are telling you the pipeline lacks the testing and guardrails to ship safely at that pace.
Reliability metrics that complement DORA
DORA tells you about the delivery pipeline. It says little about whether the running system meets user expectations. For that, borrow from SRE:
- Service level objectives (SLOs) and the error budget derived from them. An SLO of 99.9% availability gives you an explicit budget for failure, which turns "are we reliable enough?" into a number you can spend.
- Mean time between failures, which pairs with time-to-restore to describe both how often things break and how fast you recover.
The error budget is the most useful management tool in this list, because it reframes the eternal ship-fast-versus-stay-stable argument as a shared account. Budget remaining means ship. Budget exhausted means slow down and harden.
Where security metrics belong
A common gap in DevOps dashboards is that security is invisible until an incident. In a DevSecOps model, security signals are delivery metrics, because a vulnerability shipped to production is a change failure by another name. The measures worth tracking:
- Mean time to remediate (MTTR) for vulnerabilities: how long from a security finding to its fix reaching production. This is the security twin of time-to-restore.
- Vulnerability escape rate: how many issues reach production versus how many are caught pre-merge. A rising escape rate means your left-shift controls are not catching enough.
- Percentage of builds passing policy gates on the first try: a proxy for whether security is designed into the workflow or bolted on at the end.
Tracking MTTR for vulnerabilities requires knowing when a finding appeared and when the fixing change deployed, which means your security tooling has to emit events your delivery metrics can consume. When an SCA tool flags a vulnerable dependency at merge time rather than in a quarterly audit, the remediation clock starts early and MTTR drops as a direct result.
Metrics to stop reporting
Some numbers look like progress and measure noise:
- Raw lines of code or commit counts. More code is a cost, not an achievement.
- Story points completed. A capacity-planning aid, not an outcome, and trivially inflatable.
- Individual developer velocity. It corrodes collaboration and encourages hoarding easy tickets.
- Number of tests, absent any coverage or reliability context. A thousand tests that never fail on real bugs prove nothing.
The tell for a vanity metric is that you can improve it without any user being better off.
Instrumenting the pipeline
You cannot measure DORA metrics by hand. Deployment frequency and lead time come from your CI/CD system and version control. Change failure rate and restore time come from your incident and monitoring tooling. The practical move is to tag every deployment with the commit SHA and a timestamp, and every incident with the deployment that triggered it, so the four metrics compute themselves.
# Emit a deployment event CI can aggregate into DORA metrics
- name: Record deployment
run: |
curl -X POST "$METRICS_URL/deployments" \
-d "sha=$GITHUB_SHA" \
-d "service=checkout" \
-d "deployed_at=$(date -u +%FT%TZ)"
Start with whatever two metrics you can measure accurately today rather than waiting for a perfect dashboard. A rough deployment frequency and change failure rate, tracked honestly for a quarter, will teach you more than a polished dashboard of numbers nobody trusts. The Academy has deeper material on building a delivery-metrics practice.
FAQ
What are the four DORA metrics?
Deployment frequency and lead time for changes measure throughput; change failure rate and time to restore service measure stability. They are meant to be tracked together, because throughput without stability is reckless and stability without throughput is stagnant.
What DevOps metrics should I stop tracking?
Drop raw lines of code, commit counts, story points as an outcome, and individual developer velocity. They measure activity rather than value delivered and are easy to game without any user benefiting.
How do security metrics fit into DevOps success metrics?
Treat a shipped vulnerability as a change failure. Track mean time to remediate for vulnerabilities, the vulnerability escape rate from pre-merge to production, and the share of builds passing policy gates on the first try, so security becomes a delivery signal rather than an afterthought.
Why track DORA metrics together instead of individually?
Because optimizing one in isolation harms another. Pushing deployment frequency up while change failure rate rises signals a pipeline without enough testing. The balanced set keeps any single number from becoming a target you game at the expense of real outcomes.