The DevOps key metrics that actually predict how well a team delivers 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 security signals like mean time to remediate a vulnerability. Everything else tends to be a vanity number. These few, tracked honestly over time, tell you whether your pipeline is getting faster and safer or slower and more fragile, and they do it without the dashboard sprawl that makes most metrics programs collapse under their own weight.
The research behind DORA (DevOps Research and Assessment) found these four correlate with organizational performance across thousands of teams. Two measure throughput, two measure stability, and the balance between them is the whole point: speed without stability is recklessness, stability without speed is stagnation.
The four DORA metrics
Deployment frequency — how often you ship to production. Elite teams deploy on demand, multiple times a day; low performers deploy monthly or less. Frequency is a proxy for batch size, and small batches are easier to review, test, and roll back.
Lead time for changes — the elapsed time from a commit landing to that commit running in production. This measures the efficiency of your entire pipeline: review, build, test, deploy. Long lead times usually point to a manual gate or a slow test suite, not to slow developers.
Change failure rate — the percentage of deployments that cause a degraded service requiring remediation (a hotfix, rollback, or patch). It is the honest counterweight to deployment frequency. If shipping more often makes this climb, your throughput gains are borrowed against future incidents.
Time to restore service (often called MTTR for incidents) — how long it takes to recover once something breaks. Failures are inevitable; this measures whether you can detect and recover quickly. Good observability and easy rollbacks drive it down.
Read them as two pairs. Frequency and lead time are throughput; change failure rate and restore time are stability. A healthy team improves throughput without sacrificing stability, and the four metrics together make that trade-off visible instead of leaving it to anecdote.
The security metrics that belong beside them
DORA says nothing about security directly, and that gap is where a lot of risk hides. A few signals close it:
- Mean time to remediate (MTTR) vulnerabilities — the average time from a vulnerability being detected to being fixed in production. This is the security analog of incident restore time, and it is the single most telling security metric. A team that deploys ten times a day but takes ninety days to patch a critical CVE is fast in one dimension and dangerous in another.
- Vulnerability escape rate — how many vulnerabilities reach production versus how many are caught earlier in the pipeline. Rising escapes mean your left-shifted controls are not keeping up with your delivery speed.
- Percentage of deployments scanned — whether security checks actually run on every release or get skipped under deadline pressure. A gate that is routinely bypassed is not a gate.
- Mean time to detect — how long a newly disclosed vulnerability in a dependency sits in your environment before you know it is there.
That last pair is where delivery metrics and supply-chain security intersect. When a new CVE drops against a library you use, your time to detect and then time to remediate are what actually determine your exposure window. A tool such as Safeguard shortens the detect half by flagging affected projects automatically; our SCA overview explains how that inventory-to-alert path works. The Academy has a fuller treatment of instrumenting a DevSecOps pipeline for these signals.
How to measure them without a metrics theater
Two failure modes kill metrics programs. The first is measuring too much — a forty-tile dashboard nobody reads. Resist it. Start with the four DORA metrics and MTTR for vulnerabilities; add others only when a specific decision needs them.
The second is gaming. Any metric used as a target gets optimized directly, often at the expense of the thing it was meant to proxy. Push too hard on deployment frequency and teams split trivial changes to inflate the count. Watch the metrics as a balanced set — frequency alongside change failure rate, throughput alongside MTTR — so improving one at the expense of another shows up immediately.
Pull the data from systems you already have. Deployment frequency and lead time come from your CI/CD and version control. Change failure rate and restore time come from your incident tracker. Security MTTR comes from your scanner and ticketing joined on the fix commit. Automate the collection; a metric that depends on someone updating a spreadsheet will quietly stop being accurate within a month.
Using them to actually decide something
Metrics earn their keep only when they drive a decision. A climbing change failure rate is the signal to invest in test coverage before adding features. A long vulnerability MTTR is the case for automating remediation or tightening SLAs on patch tickets. A low percentage-of-deployments-scanned is the argument for making the security gate mandatory rather than advisory. Track the trend, not the absolute number — where you are heading matters more than where you happen to sit this quarter.
FAQ
What are the four DORA metrics?
Deployment frequency, lead time for changes, change failure rate, and time to restore service. The first two measure delivery throughput; the second two measure stability. Together they predict software delivery performance without requiring a large metrics program.
Why include security metrics with DevOps metrics?
Because DORA measures delivery speed and stability but not risk. A team can score elite on all four while leaving critical vulnerabilities unpatched for months. Adding mean time to remediate vulnerabilities and vulnerability escape rate closes that blind spot.
What is MTTR in a DevOps context?
MTTR is used two ways. For incidents it is mean time to restore service after a failure. For security it is mean time to remediate a vulnerability from detection to production fix. Both measure recovery speed, which matters more than trying to prevent every failure.
How many DevOps metrics should a team track?
Few. Start with the four DORA metrics plus vulnerability MTTR. Add more only when a specific decision requires the data. Large dashboards get ignored, and any single metric used as a hard target tends to get gamed at the expense of what it was meant to measure.