Failed deployment recovery time measures how long it takes to recover from a deployment that failed and needed immediate intervention. Time to remediate measures how long a known vulnerability stays open. They start on different events, stop on different events, and answer different questions, so keep them as two separate numbers.
Two clocks, two starting points
DORA's guide defines failed deployment recovery time as the time it takes to recover from a deployment that fails and requires immediate intervention. The trigger is a deployment. The clock starts when that deployment goes wrong and stops when service is restored, usually by rollback or hotfix.
Time to remediate starts when a vulnerability is known to affect you, which could be the day a scan reports it or the day an advisory is published, and stops when the fix is in production. No deployment of yours failed. The risk existed in software you already shipped.
| Failed deployment recovery time | Time to remediate | |
|---|---|---|
| Starts | A deployment fails | A vulnerability is identified in your software |
| Stops | Service restored | Fix deployed, or risk accepted |
| Caused by | Your change | Often a new advisory against old code |
| Owner | Delivery team | Delivery team with security input |
| Typical unit | Minutes to hours | Days to weeks |
Why merging them misleads
If you fold vulnerability fixes into recovery time, one slow dependency upgrade that sat in a backlog for six weeks drags the number up and makes your incident response look bad. The reverse also happens: a fast rollback hides a long exposure.
DORA's own guide also notes a shift in wording from MTTR to failed deployment recovery time. The older MTTR label was used loosely for many things, which is the kind of confusion to avoid here. We cover that wider confusion in MTTR for incident response vs vulnerability remediation.
Where the two meet
They do overlap in one case. If a deployed change introduced a vulnerability and you must roll back urgently, that is a failed deployment, and recovery time applies. If that same vulnerability was already live for weeks before anyone noticed, the exposure window is a separate fact you should also record.
A useful record for each such event holds:
- Time the change was deployed.
- Time the problem was detected.
- Time service was restored.
- Time the underlying weakness was fully fixed, if different.
From these you can compute recovery time and exposure time without arguing about definitions.
What to report
Report recovery time per service with the median and the slowest cases, because averages hide the bad week. Report time to remediate by severity, so critical issues are not averaged with low ones. Put them in separate rows of the same review so that the conversation covers both speed of recovery and length of exposure.
Quick check
Which one should a security team own?
Time to remediate is the security team's main measure, shared with the people who ship fixes. Recovery time belongs to the delivery team, with security looped in when the cause was a security change.
Can one tool give me both?
Delivery tooling usually gives you deployment events, and scanning tooling gives you finding dates. You join them by service and date. Expect to do a small amount of manual setup.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are tracked from detection to closure. That lifecycle is the time to remediate clock.
How Safeguard fits
Safeguard offers dependency scanning, continuous monitoring and autonomous remediation with fix PRs (off by default, every category on Manual), which helps shorten the time a known vulnerability stays open. Run a free scan at gold.safeguard.sh/scan.
Sources
- DORA, DORA's software delivery performance metrics: https://dora.dev/guides/dora-metrics/
Last reviewed: 19 October 2026.
