Lexicon
MTTR
MTTR is mean time to resolution: the average time from failure to recovery. What it measures, its cousins MTTD and MTTA, and how to actually reduce it.
On this page
Definition
MTTR is mean time to resolution, the average elapsed time from a failure occurring to service being restored. It sits in a family of incident metrics alongside MTTD, mean time to detect, and MTTA, mean time to acknowledge, each measuring one segment of the incident lifecycle.
What it means in observability
MTTR is the headline number for operational maturity because it compresses a whole capability into one duration: how fast does this organization notice, diagnose, and fix trouble. Its practical value is decompositional. Total resolution time splits into detection, diagnosis, repair, and verification, and each segment points at a different investment: better alerting shortens detection, better observability shortens diagnosis, better deployment tooling shortens repair. Most organizations discover their time hides in diagnosis, the stretch spent figuring out what is actually wrong.
How it works in practice
MTTR is computed from incident timelines, when impact started, when it was detected, when it was resolved, averaged over the incidents in a period. Observability bears on the middle segments most. Detection time falls when monitors watch symptoms users feel rather than causes engineers guess at, and diagnosis time falls when signals are correlated, so the path from alert to trace to log is a pivot rather than an expedition across tools.
Where it gets hard
Averages mislead: one nine hour outage buried among twenty quick fixes yields a comfortable mean and a miserable quarter, so distributions and percentiles tell truer stories. Definitions drift too, resolved versus mitigated versus root caused, and comparisons across teams or vendors quietly assume everyone measures alike. Worst, the metric is gameable, and teams managed on MTTR alone learn to close tickets rather than fix systems.
Where Tsuga fits
Tsuga attacks the diagnosis segment: correlated signals, ongoing alert views with investigation actions, the Explain panel for ranking what changed, and AI augmented troubleshooting. The minutes MTTR is made of are mostly spent looking, and Tsuga shortens the looking.
Related terms
- AIOpsAIOps is the application of machine learning and artificial intelligence to IT operations: detecting anomalies, correlating and grouping alerts, suggesting root causes, and increasingly, powering assistants that investigate telemetry conversationally.
- APMAPM, application performance monitoring, is the practice and product category focused on the health of applications in production: request rates, error rates, latency, and the transaction level detail needed to explain them.
- Error budgetAn error budget is the amount of unreliability an SLO permits: one hundred percent minus the target.
- ObservabilityObservability is the ability to understand what is happening inside a system from the data it emits: its logs, metrics, and traces.
- SLOAn SLO, service level objective, is a target for how reliable a service should be, expressed as a measured indicator held over a time window: 99.9 percent of requests succeed over 30 days, or 95 percent of checkouts complete in under two seconds.
- TraceA trace is the end to end record of one request or workflow as it moves through a system, composed of all the spans that share a single trace ID.