Remedy What is MTTR, and where does AI actually help?
MTTR is an average duration for an incident-response outcome. Define the start and finish first, then assess whether AI reduces the time spent reaching that outcome.
Define the R before comparing results
MTTR can mean mean time to repair, recover, respond or resolve. Those definitions measure different events. A team that stops its clock when service returns cannot directly compare its number with a team that waits for a permanent repair and follow-up work. Atlassian’s incident-metrics guide explains these common variations.
For this guide, “time to recovery” begins at the recorded start of customer impact and ends when the agreed service criteria are restored. “Time to verified repair” ends later, once the permanent change has passed its release and incident-specific verification. Choose a definition that your organisation can observe reliably and use it consistently.
A simple calculation, with an important limit
Add the elapsed recovery durations for the incidents in a period, then divide by the number of incidents. If three illustrative incidents take 20, 40 and 120 minutes, the mean is 60 minutes. The median is 40 minutes. Both describe the same sample but highlight different aspects of it.
These numbers are a worked example, not Remedy results. The long incident has a large effect on the average, and the small sample says little about future performance. Publish the count, severity mix and chosen clock boundaries alongside an average.
Do not exclude difficult unresolved incidents without making that exclusion visible. Otherwise a period can look better simply because its hardest cases have not yet closed. Keep an open-incident view and inspect long-running cases separately from the closed-incident calculation.
Break the response into observable stages
A single average does not explain where time is lost. Record timestamps for the stages your workflow can reliably observe, then identify delays with the greatest effect on the outcome.
| Stage | Useful observation | Possible source of delay |
|---|---|---|
| Detection | First reliable signal of impact | Missing monitoring or unclear user reports |
| Triage | Owner and impact identified | Duplicates, routing or missing context |
| Diagnosis | A testable cause established | Version mismatch or poor reproduction |
| Candidate | A proposed repair is ready | Environment setup or incomplete requirements |
| Review and release | Approved change reaches the target | Review queue, rollout or release windows |
| Verification | Incident-specific criteria pass | Weak acceptance checks or missing runtime evidence |
Where AI can help reduce the work
AI can help organise a report, summarise permitted evidence and identify information that is missing. It can connect an error to likely source locations and prepare a hypothesis for an engineer to challenge. The practical benefit depends on whether those outputs save time in the next stage, not on how quickly the summary appears.
For a repeatable defect, candidate generation and test preparation may shorten the engineering work. For an unclear operational incident, organising the timeline may be more valuable than generating code. In both cases, retain links to the underlying observations so a reviewer can check the explanation.
Measure total effort, including time spent correcting the agent’s assumptions. A patch that arrives quickly but needs extensive review can increase the workload. A concise diagnosis that correctly asks for one missing observation may be more useful even when it produces no patch.
Where AI does not remove the bottleneck
An agent cannot compensate for every missing test fixture, inaccessible environment, contradictory requirement or unobservable production condition. It also cannot decide your organisation’s acceptable business risk merely by predicting the next code change.
Review queues and release windows can dominate elapsed time even if implementation becomes faster. A mobile-store release may wait on processes outside the repair tool. Database changes can require separate planning and approval. Attribute those delays accurately instead of claiming that model speed determines the full recovery outcome.
If the failure is caused by a dependency outside your control, restoration may require a workaround or fallback. That is still useful incident response, but it should not be reported as a permanent fix to the external dependency.
Recovery and permanent repair need different evidence
A rollback can restore service before anyone fully understands the defect. A restart may temporarily clear a symptom. Track the recovery milestone and the follow-up repair separately, so successful mitigation does not erase recurring work. Google’s incident-management guidance emphasises coordinated response and clear responsibilities during incidents.
For an illustrative worker failure, restarting the worker might resume processing. A durable repair might later change error handling and add a regression test. The first outcome concerns service recovery; the second concerns preventing the same failure under the tested conditions. Neither implies that every future worker failure is solved.
Verification must correspond to the claim being made. A service-health check may support recovery. A replay of the original failing input and a suitable observation window may provide evidence for the permanent repair. Choose the evidence before using its result in a metric.
Run a fair before-and-after evaluation
Use the same incident definition, severity categories and clock boundaries on both sides of the comparison. Record workload changes, staffing, observability improvements and release-process changes. A lower average after adopting a tool does not by itself establish that the tool caused the improvement.
Include failed attempts and cases where the agent declined to act. Capture engineering time as well as elapsed time, and review the quality of accepted changes. Count regressions, reopenings and inconclusive verification alongside completed repairs.
A small pilot can reveal workflow friction without supporting a broad percentage claim. Present the sample size and limitations plainly. If the main improvement is faster triage, say that; avoid relabelling it as a proven reduction in end-to-end recovery.
How this relates to Remedy
Remedy’s foundation is designed to keep incident evidence, diagnosis, candidate repair and verification connected. Root-cause analysis addresses the investigation stage; verified software repair addresses the evidence needed at the end. Runtime Agent capabilities remain in development, while Probes and connectors have separate status labels.
No measured MTTR reduction is claimed here for Remedy. An early-access assessment should agree the supported input, baseline, acceptance checks and outcome measurements before work begins. It should also record where the workflow stops and requires engineering judgement.
For teams choosing a product, the tool comparison maps the different entry points. Security autofix, PR repair and production-incident orchestration can each help a specific stage; they are not interchangeable measures of incident recovery.
From bug report to verified fix.
See how Remedy connects evidence, diagnosis, repair, deterministic checks and production verification.
Explore the complete workflow →