Warum ist die MTTR so wichtig?
Die Mean Time to Recovery — kurz MTTR, auch Time to Recovery genannt — misst, wie schnell ein Team nach einem Ausfall den Normalbetrieb wiederherstellt. Sie ist eine der vier DORA-Metriken und zeigt, wie gut die Incident-Response-Prozesse funktionieren — gute Teams schaffen es in unter einer Stunde.
Auch bekannt als: MTTR · Mean Time to Repair · Mean Time to Restore · Mittlere Wiederherstellungszeit
Ist Mean Time to Recovery (MTTR) bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Die Mean Time to Recovery (MTTR) misst die durchschnittliche Zeit, die ein Team benötigt, um nach einer Störung den Normalbetrieb wiederherzustellen — gemessen von der Erkennung des Vorfalls bis zur vollständigen Wiederherstellung. Sie ist eine Stabilitätsmetrik und beantwortet nicht die Frage, ob etwas ausfällt, sondern wie schnell man sich davon erholt. In der Praxis wird teils zwischen MTTR (Recovery) und verwandten Kennzahlen wie Mean Time to Detect oder Mean Time to Resolve unterschieden; entscheidend ist eine konsistente Definition.
Als eine der vier DORA-Metriken ergänzt die MTTR die Change Failure Rate: Während die CFR misst, wie oft etwas schiefgeht, misst die MTTR, wie gut die Organisation damit umgeht. Diese Sichtweise verschiebt den Fokus von der Vermeidung jedes denkbaren Fehlers hin zu schneller, geübter Erholung — ein Kernprinzip von Site Reliability Engineering. High Performer stellen den Betrieb laut DORA-Klassifikation in unter einer Stunde wieder her. Im DORA-Report selbst hat die Kennzahl übrigens mehrfach den Namen gewechselt: aus Time to Restore Service wurde 2023 die Failed Deployment Recovery Time — gemeint ist in allen Varianten dieselbe Zeit bis zur Wiederherstellung, die Time to Recovery.
In industriellen Umgebungen ist die MTTR besonders kritisch, weil Ausfallzeit unmittelbar Produktionsverluste bedeutet. Eine niedrige MTTR setzt funktionierende Observability voraus — ohne saubere Logs, Metriken und Traces wird die Diagnose zum Blindflug: Jede Minute Stillstand läuft mit, während das Team noch sucht, wo überhaupt gesucht werden muss. Ein typischer Stolperstein ist es, die MTTR über sehr viele kleine, harmlose Incidents zu schönen oder umgekehrt seltene Großausfälle als Mittelwert zu verzerren. Hilfreich sind ergänzend Perzentile und automatisierte Rollback-Mechanismen, die die Wiederherstellung verlässlich beschleunigen.
Automatisierter Rollback senkt die MTTR
Ein Fertigungsbetrieb verknüpft Health-Checks mit automatischem Rollback auf die letzte stabile Version. Statt manueller Fehlersuche über Stunden ist der Normalbetrieb innerhalb weniger Minuten wiederhergestellt.
Observability als MTTR-Hebel
Ein IT-Team führt durchgängiges Distributed Tracing ein, um die Ursache von Störungen schneller zu lokalisieren. Die Diagnosezeit sinkt deutlich, und die MTTR fällt von mehreren Stunden auf unter 30 Minuten.
Wo verlieren Sie Zeit bei der Wiederherstellung?
MTTR entscheidet, wie schnell Sie nach einem Ausfall wieder laufen — der Engpass sitzt im Erkennen, Beheben oder Zurückrollen. Zwei Klicks ordnen ein.
Wo geht die meiste Zeit verloren?
- Was genau misst die MTTR — und was nicht?
- Die MTTR misst die Zeit von der Erkennung einer Störung bis zur Wiederherstellung des Normalbetriebs. Sie sagt nichts darüber aus, wie oft Störungen auftreten — das deckt die Change Failure Rate ab. Beide Metriken zusammen beschreiben die Stabilitätsdimension der DORA-Metriken.
- Warum ist eine niedrige MTTR wichtiger als das Vermeiden jedes Ausfalls?
- In komplexen Systemen lassen sich nicht alle Fehler verhindern — Ausfälle treffen jedes Team, auch die Elite-Teams aus den DORA-Reports. Eine kurze MTTR macht die unvermeidbaren Ausfälle beherrschbar und begrenzt die Auswirkung. Site Reliability Engineering setzt deshalb stark auf schnelle, geübte Wiederherstellung statt auf die Illusion fehlerfreier Systeme.
- Welche Faktoren verbessern die MTTR am stärksten?
- Gute Observability beschleunigt die Diagnose, automatisierte Rollbacks und Runbooks beschleunigen die Behebung, und geübte Incident-Response-Prozesse vermeiden Reibungsverluste. Kleine, häufige Deployments helfen zusätzlich, weil der fehlerhafte Change schneller eingegrenzt werden kann.
- Wie berechnet man die MTTR?
- Die Summe aller Wiederherstellungszeiten eines Zeitraums geteilt durch die Anzahl der Vorfälle. Ein Beispiel: Drei Störungen mit 30, 60 und 90 Minuten Ausfallzeit ergeben eine MTTR von 60 Minuten. Wichtig ist ein konsistenter Startpunkt — üblicherweise die Erkennung der Störung, nicht ihr tatsächlicher Beginn.
- Was ist eine gute Time to Recovery nach DORA?
- Elite-Teams stellen den Betrieb laut DORA in unter einer Stunde wieder her, gute Teams innerhalb eines Tages — langsame Organisationen brauchen eine Woche bis einen Monat. Wichtiger als der Benchmark ist der Trend: Eine kontinuierlich sinkende Time to Recovery zeigt, dass Observability, automatisierte Rollbacks und Incident-Response ineinandergreifen.
- Was ist der Unterschied zwischen MTTR und MTBF?
- Die MTBF (Mean Time Between Failures) misst, wie lange ein System zwischen zwei Ausfällen läuft, die MTTR, wie lange die Wiederherstellung danach dauert. Die MTBF ist damit eine Zuverlässigkeits-, die MTTR eine Erholungskennzahl. Berechnet wird die MTBF als gesamte Betriebszeit geteilt durch die Anzahl der Ausfälle: 1.000 Betriebsstunden mit vier Ausfällen ergeben eine MTBF von 250 Stunden. Für nicht reparierbare Bauteile spricht man stattdessen von der MTTF (Mean Time To Failure), weil es kein „zwischen" gibt — das Teil wird getauscht, nicht instand gesetzt. In der Anlagenverfügbarkeit greifen beide Werte ineinander: Verfügbarkeit ist MTBF geteilt durch die Summe aus MTBF und MTTR.
- Was unterscheidet MTTD, MTTA und MTTR?
- Die drei Kennzahlen zerlegen denselben Vorfall in aufeinanderfolgende Abschnitte. Die MTTD (Mean Time to Detect) misst, wie lange es dauert, bis die Störung überhaupt bemerkt wird. Die MTTA (Mean Time to Acknowledge) misst die Zeit vom ausgelösten Alarm bis zu dem Moment, in dem ein Mensch aus der Rufbereitschaft ihn quittiert und übernimmt. Die MTTR schließt die Kette und misst bis zur wiederhergestellten Funktion. Die Trennung lohnt sich, weil sie den Engpass sichtbar macht: Liegt der Großteil der Ausfallzeit in der MTTD, fehlt Monitoring; liegt er in der MTTA, ist der Eskalationsweg das Problem und kein technisches. Verwirrend ist dabei, dass MTTR selbst mehrdeutig belegt ist — Repair, Recovery, Restore und Respond meinen unterschiedliche Endpunkte. Entscheidend ist weniger, welche Variante ein Team wählt, als dass alle dieselbe meinen.
Wo steht Ihr Team bei Mean Time to Recovery (MTTR)?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance