MTTR (Mean Time to Recovery, Repair, Respond oder Resolve) ist die durchschnittliche Zeit, die vergeht, bis ein System nach einem Ausfall wieder funktioniert. Sie wird als gesamte Wiederherstellungszeit geteilt durch die Anzahl der Incidents berechnet und ist zusammen mit MTTD, MTTA und MTBF eine zentrale Kennzahl für Incident Response.
Das Wichtigste in Kürze
- MTTR hat vier gängige Bedeutungen (Repair, Recovery, Respond, Resolve). Legen Sie fest, welche Sie meinen, bevor Sie Zahlen vergleichen.
- Formel: MTTR = Summe der Incident-Dauern / Anzahl der Incidents. Beispiel: 180 Minuten bei 4 Incidents ergeben 45 Minuten MTTR.
- Zerlegen Sie MTTR in Phasen (Erkennen, Bestätigen, Diagnose, Mitigation), um zu sehen, wo Zeit verloren geht. Meist dominiert die Diagnose.
- Incident-Dauern sind stark schief verteilt. Betrachten Sie deshalb Median und p90 zusätzlich zum Mittelwert und nutzen Sie MTTR nie als individuelles Leistungsziel.
Was ist MTTR?
MTTR ist die durchschnittliche Zeit, bis ein ausgefallenes System wieder funktioniert. Sie ist die meistgenutzte Incident-Kennzahl in IT-Betrieb und Site Reliability Engineering, weil sie eine Frage beantwortet, die jede Engineering-Leitung stellt: Wenn etwas kaputtgeht, wie lange sind Nutzer betroffen? Die Grundformel ist einfach:
MTTR = Summe der Incident-Dauern / Anzahl der Incidents
Hatte Ihr Team im letzten Monat vier Produktions-Incidents mit 30, 45, 90 und 15 Minuten Dauer, ergibt das 180 Minuten und eine MTTR von 180 / 4 = 45 Minuten.
Die Schwierigkeit: Das „R“ ist mehrdeutig. Teams, Hersteller und Frameworks meinen damit Unterschiedliches, und diese Unterschiede sind wichtig, sobald Sie Zahlen vergleichen oder Ziele setzen.
Die vier Bedeutungen von MTTR
| Kennzahl | Misst | Beginn | Ende |
|---|---|---|---|
| Mean Time to Repair | Reine Reparaturzeit | Reparaturarbeit beginnt | Komponente ist repariert |
| Mean Time to Recovery (Restore) | Dauer der Beeinträchtigung für Nutzer | Ausfall beginnt | Service ist für Nutzer wiederhergestellt |
| Mean Time to Respond | Reaktionsgeschwindigkeit | Alert wird ausgelöst | Responder beginnt zu arbeiten (oft MTTA plus Triage) |
| Mean Time to Resolve | Gesamter Lebenszyklus | Ausfall beginnt | Ursache behoben, Folgemaßnahmen erledigt |
Für Software-Services ist Mean Time to Recovery meist am aussagekräftigsten, weil sie misst, wie lange Nutzer betroffen sind. Die Wiederherstellung erfolgt oft durch Mitigation, etwa per Rollback, Feature Flag oder Failover, lange bevor der eigentliche Bug behoben ist. Auch das DORA-Forschungsprogramm nutzt diese Sicht: Seine Stabilitätskennzahl heißt inzwischen Failed Deployment Recovery Time (früher Time to Restore Service) und misst, wie schnell sich ein Team von einer Änderung erholt, die einen Fehler in Produktion verursacht hat.
MTTD, MTTA, MTTR und MTBF auf der Incident-Zeitachse
MTTR lässt sich am besten verbessern, wenn Sie einen Incident in Phasen zerlegen. Jede Phase hat eine eigene Kennzahl:
- Ausfall beginnt. Nutzer sind ab jetzt betroffen.
- Erkennung (MTTD, Mean Time to Detect). Zeit vom Ausfallbeginn, bis Monitoring oder ein Mensch ihn bemerkt.
- Bestätigung (MTTA, Mean Time to Acknowledge). Zeit vom Alert, bis eine Person im Bereitschaftsdienst ihn annimmt.
- Diagnose. Zeit, bis klar ist, was kaputt ist und warum. Diese Phase wird selten separat gemessen, ist aber meist die längste.
- Mitigation und Wiederherstellung. Rollback, Failover, Skalierung oder Hotfix stellen den Service wieder her. Hier endet die Time to Recovery.
- Abschluss. Die eigentliche Ursache ist behoben und die Postmortem-Maßnahmen sind umgesetzt.
MTBF (Mean Time Between Failures) liegt außerhalb des Incidents: Sie misst die durchschnittliche Betriebszeit zwischen zwei Ausfällen und beschreibt damit, wie oft etwas kaputtgeht, nicht wie schnell Sie sich erholen. Die verwandte Kennzahl MTTF (Mean Time to Failure) wird für Komponenten verwendet, die ersetzt statt repariert werden, etwa Festplatten.
| Kennzahl | Formel | Aussage |
|---|---|---|
| MTTD | Summe (erkannt − begonnen) / Incidents | Qualität von Monitoring und Alerting |
| MTTA | Summe (bestätigt − alarmiert) / Incidents | Zustand von On-Call und Alert-Routing |
| MTTR (Recovery) | Summe (wiederhergestellt − begonnen) / Incidents | Gesamte Nutzerauswirkung pro Incident |
| MTBF | Gesamte Betriebszeit / Anzahl der Ausfälle | Wie häufig Ausfälle auftreten |
Rechenbeispiel: von MTTR zur Verfügbarkeit
Nehmen Sie einen Monat mit 30 Tagen (720 Stunden) und die vier Incidents von oben mit zusammen 3 Stunden Ausfallzeit für Nutzer.
- MTTR = 180 min / 4 = 45 min (0,75 h)
- MTBF = (720 h − 3 h) / 4 = 179,25 h
- Verfügbarkeit = MTBF / (MTBF + MTTR) = 179,25 / 180 = 99,58 %
Die Formel zeigt die zwei Hebel der Zuverlässigkeit: seltener ausfallen (MTBF erhöhen) oder schneller wiederherstellen (MTTR senken). In komplexen verteilten Systemen, in denen Fehler unvermeidlich sind, ist schnellere Wiederherstellung meist der günstigere Hebel. Eine Halbierung der MTTR würde die Verfügbarkeit im Beispiel auf etwa 99,79 % heben, ohne einen einzigen Incident zu verhindern. Deshalb passen SLOs und MTTR zusammen: Jede eingesparte Minute Recovery-Zeit ist Error Budget, das Ihnen bleibt.
Warum MTTR in die Irre führen kann
MTTR ist nützlich, aber ein grobes Instrument. Kennen Sie die Grenzen, bevor Sie die Zahl an das Management berichten:
- Schiefe Verteilung. Incident-Dauern folgen einer Long-Tail-Verteilung: viele kurze und wenige sehr lange Incidents. Ein einziger achtstündiger Ausfall kann den Monatsmittelwert verdoppeln. Auswertungen öffentlicher Incident-Daten wie der VOID-Report haben gezeigt, dass der Mittelwert solche Daten schlecht zusammenfasst. Berichten Sie Median und p90 zusätzlich zum Mittelwert.
- Kleine Stichproben. Bei fünf Incidents pro Quartal sind Schwankungen von Monat zu Monat überwiegend Rauschen. Betrachten Sie Trends über längere Zeiträume.
- Uneinheitliche Startzeitpunkte. Wenn „Beginn“ mal den ersten Alert und mal die erste Nutzerauswirkung meint, sind Zahlen nicht vergleichbar. Rekonstruieren Sie den echten Beginn aus der Telemetrie.
- Goodharts Gesetz. Wird MTTR zum Ziel, schließen Teams Incidents womöglich zu früh, teilen sie auf oder melden kleine gar nicht mehr. Koppeln Sie MTTR niemals an individuelle Leistungsbewertungen.
- Vermischte Schweregrade. Wer eine leichte Degradation mit einem Totalausfall mittelt, verschleiert beides. Segmentieren Sie MTTR nach Schweregrad und Service.
MTTR in der Praxis messen
Verlässliche MTTR-Werte hängen weniger von der Formel ab als von konsistenten Daten. Ein praxistaugliches Vorgehen:
- Definieren, was ein Incident ist. Einigen Sie sich auf Schweregrade und darauf, welche Ereignisse als Incident erklärt werden, etwa jeder Burn-Rate-Page oder jede für Kunden sichtbare Degradation oberhalb eines Schwellwerts.
- Zeitstempel aus der Telemetrie statt aus dem Chat. Der Beginn der Auswirkung ist der Moment, in dem sich der SLI verschlechtert hat, nicht das Öffnen eines Tickets. Erkennung ist der erste Alert, Bestätigung die Annahme durch On-Call, Wiederherstellung die Rückkehr des SLI zum Normalwert.
- Phasen getrennt erfassen. Speichern Sie für jeden Incident Beginn, Erkennung, Bestätigung, Mitigation und Abschluss.
- Verteilungen berichten. Zeigen Sie Anzahl, Median, p90 und Mittelwert je Schweregrad und Service über mindestens ein Quartal.
Ein kleines Beispiel zeigt, warum die Phasen entscheidend sind:
| Incident | Erkennen | Bestätigen | Diagnose | Mitigation | Gesamt |
|---|---|---|---|---|---|
| A | 4 min | 3 min | 18 min | 5 min | 30 min |
| B | 12 min | 2 min | 26 min | 5 min | 45 min |
| C | 6 min | 9 min | 65 min | 10 min | 90 min |
| D | 2 min | 1 min | 8 min | 4 min | 15 min |
Die Diagnose macht hier 117 von 180 Minuten aus, also rund 65 % der Gesamtzeit. Schnelleres Alarmieren würde die MTTR kaum verändern, bessere Korrelation und mehr Kontext dagegen deutlich. Genau deshalb lohnt es sich, die Phasen getrennt sichtbar zu machen, statt nur eine einzige Durchschnittszahl zu berichten.
So senken Sie die MTTR
Verbesserungen entstehen, wenn Sie jede Phase der Zeitachse einzeln angehen.
Schneller erkennen
Alarmieren Sie auf Symptome, die Nutzer spüren (SLO-Burn-Rate, Fehlerrate, Latenz), statt auf Ursachen wie CPU-Last. Nutzen Sie Anomalieerkennung für Metriken ohne feste Schwellwerte und synthetische Checks für kritische Abläufe, damit Sie Ausfälle auch bei wenig Traffic bemerken.
Schneller bestätigen
Routen Sie Alerts über einen Service-Katalog an das zuständige Team, deduplizieren Sie sie und fassen Sie zusammengehörige Alerts zu einem Incident zusammen. Halten Sie Bereitschaftsdienste nachhaltig. Alert-Müdigkeit erhöht die MTTA direkt.
Schneller diagnostizieren
Hier geht die meiste Zeit verloren. Korrelieren Sie Metriken, Logs und Traces über gemeinsamen Kontext wie Trace-IDs und Resource-Attribute und halten Sie eine aktuelle Topologie bereit, damit Responder vor- und nachgelagerte Abhängigkeiten sehen. Blenden Sie Deployments und Konfigurationsänderungen in jedes Diagramm ein: Ein großer Teil der Incidents wird durch eine Änderung ausgelöst, deshalb ist „Was hat sich geändert?“ oft die schnellste Frage.
Schneller wiederherstellen
Machen Sie Mitigation günstig: Rollbacks per Klick, Feature Flags, automatisches Failover und Runbooks als Code. Üben Sie das in Game Days, damit es unter Druck funktioniert.
Aus jedem Incident lernen
Blameless Postmortems mit nachverfolgten Maßnahmen erhöhen langfristig die MTBF und verhindern, dass derselbe Fehler Sie zweimal Zeit kostet. Halten Sie in jedem Postmortem auch fest, welche Phase am längsten gedauert hat und warum, zum Beispiel fehlende Traces, unklare Zuständigkeiten oder ein Runbook, das nicht mehr stimmte.
Wie Obseria die MTTR senkt
Obseria verkürzt jede Phase der Incident-Zeitachse. Burn-Rate-Alerts und Anomalieerkennung auf OpenTelemetry-Metriken, Logs und Traces verkürzen die Erkennung, korrelierte Alerts werden zu einem Problem gebündelt und an das zuständige Team geroutet. Für die Diagnose zeigt Obseria TopoGraph betroffene Services und Infrastruktur im Kontext, Deployment Tracking hebt aktuelle Änderungen hervor und Obseria Intelligence führt eine agentische Root-Cause-Analyse durch, die eine Beweiskette statt eines Stapels Dashboards liefert. Automation-Workflows können anschließend Rollbacks oder Runbooks auslösen, und Incident-Zeitachsen werden automatisch aufgezeichnet, sodass MTTD, MTTA und MTTR aus der Telemetrie gemessen werden statt aus dem Gedächtnis.