MTTR (Mean Time to Recovery bzw. Repair) ist die durchschnittliche Zeit vom Beginn eines Vorfalls, bis der Dienst wieder funktioniert. MTTA (Mean Time to Acknowledge) ist die durchschnittliche Zeit von einem Alarm, bis jemand bestätigt, dass er sich darum kümmert. MTBF (Mean Time Between Failures) ist die durchschnittliche Zeit, in der ein Dienst zwischen zwei Vorfällen normal läuft. Zusammen beschreiben sie die Zuverlässigkeit: MTBF sagt, wie oft etwas ausfällt, MTTA, wie schnell Sie reagieren, und MTTR, wie lange Kunden betroffen sind.
Dieser Leitfaden behandelt die Definitionen, die Formeln, ein Rechenbeispiel mit Zahlen, welche Zeitstempel Sie erfassen sollten und die praktischen Maßnahmen, die jede Kennzahl verbessern.
Die Kennzahlen und was sie messen
MTTR: vier Bedeutungen, ein Kürzel
MTTR ist die meistzitierte Incident-Kennzahl und zugleich die verwirrendste, denn das R steht je nach Anwender für etwas anderes:
Mean Time to Repair: vom Beginn der Reparaturarbeiten, bis die Lösung umgesetzt ist. Üblich bei Hardware und Instandhaltung.
Mean Time to Recovery (oder Restore): vom Beginn des Ausfalls, bis der Dienst für die Nutzer wieder funktioniert. Die nützlichste Variante für Websites und APIs.
Mean Time to Respond: vom Alarm, bis das Team handelt. Nah an der MTTA.
Mean Time to Resolve: bis der Vorfall vollständig abgeschlossen ist, einschließlich der Nacharbeit, die eine Wiederholung verhindert.
Keine davon ist falsch. Entscheidend ist, dass Sie sich für eine entscheiden, die Definition festhalten und sie konsequent verwenden. Ihre „Recovery“-Zahl mit der „Repair“-Zahl eines anderen zu vergleichen, sagt nichts aus. In diesem Artikel bedeutet MTTR Mean Time to Recovery: vom Zeitpunkt, an dem der Dienst ausfiel, bis er wieder funktionierte.
MTTD und MTTA: die Reaktion vor der Reparatur
MTTD (Mean Time to Detect) ist die Zeit vom Beginn eines Vorfalls, bis das Monitoring einen Alarm auslöst. MTTA ist die Zeit von diesem Alarm, bis eine Person ihn bestätigt. Beide sind Teil der MTTR, und genau deshalb sind sie so wichtig: Niemand kann ein Problem beheben, von dem er nichts weiß.
MTBF: wie oft etwas ausfällt
MTBF ist die durchschnittliche Betriebszeit zwischen Vorfällen. Je höher, desto besser. Die verwandte MTTF (Mean Time to Failure) wird für Dinge verwendet, die ersetzt statt repariert werden, etwa Festplatten; für Onlinedienste ist MTBF die richtige Kennzahl.
Die Formeln
MTTD = Gesamtzeit von Vorfallbeginn bis Alarm / Anzahl der Vorfälle
MTTA = Gesamtzeit von Alarm bis Bestätigung / Anzahl der Vorfälle
MTTR = Gesamtzeit von Vorfallbeginn bis Wiederherstellung / Anzahl der Vorfälle
MTBF = Gesamte Betriebszeit ohne Vorfälle / Anzahl der Vorfälle
Verfügbarkeit = MTBF / (MTBF + MTTR)
Die letzte Zeile zeigt, warum beide Seiten zählen. Sie können die Verfügbarkeit verbessern, indem Sie weniger Vorfälle haben (höhere MTBF) oder sie verkürzen (niedrigere MTTR). Das Verkürzen ist oft deutlich günstiger.
Ein Rechenbeispiel
Hier ein Beispielmonat für einen Onlineshop mit vier Vorfällen. Die Zahlen sind zur Veranschaulichung erfunden, aber die Zeitstempel sind genau die, die jedes Monitoring-Tool liefert.
VorfallBeginnAlarmBestätigtWiederhergestelltErkennungBestätigungWiederherstellungCheckout 50303:1203:1303:1603:191 Min.3 Min.7 Min.API-Timeouts10:0510:0610:0810:411 Min.2 Min.36 Min.Login-Fehler14:3014:3114:4515:021 Min.14 Min.32 Min.Suche down22:5022:5122:5623:151 Min.5 Min.25 Min.
Jetzt wenden wir die Formeln an:
MTTD = (1 + 1 + 1 + 1) / 4 = 1 Minute.
MTTA = (3 + 2 + 14 + 5) / 4 = 6 Minuten.
MTTR = (7 + 36 + 32 + 25) / 4 = 25 Minuten.
MTBF: Ein Monat mit 30 Tagen hat 43.200 Minuten. Abzüglich 100 Minuten Ausfallzeit bleiben 43.100. Geteilt durch 4 Vorfälle ergibt sich eine MTBF von 10.775 Minuten, rund 7,5 Tage.
Verfügbarkeit = 10.775 / (10.775 + 25) = 99,77 %.
Zwei Dinge fallen auf. Die 14 Minuten bis zur Bestätigung beim Login-Vorfall treiben die MTTA von etwa 3 auf 6 Minuten hoch – es lohnt sich also zu fragen, warum niemand diesen Alarm angenommen hat. Und mit 99,77 % verfehlt dieser Shop ein Ziel von 99,9 % deutlich, das nur 43 Minuten pro Monat erlaubt. Wenn Sie solche Ziele festlegen, lesen Sie SLA vs. SLO vs. SLI, um zu verstehen, wie sie zusammenhängen.
Stellen Sie sich nun denselben Monat mit Checks alle fünf Minuten und ohne Bestätigungsschritt vor. Die Erkennung könnte bis zu fünf statt einer Minute dauern und jedem Vorfall bis zu vier Minuten hinzufügen. Die MTTR steigt von 25 auf bis zu 29 Minuten, bevor irgendjemand etwas anders gemacht hat.
Welche Zeitstempel Sie erfassen sollten
Sie brauchen vier Zeitstempel pro Vorfall. Die meisten liefert das Monitoring direkt:
Beginn: der erste fehlgeschlagene Check. Externes Monitoring erfasst ihn auch dann, wenn Ihre Server nichts protokollieren.
Alarm: wann der Fehler bestätigt wurde und die Benachrichtigung rausging.
Bestätigt: wann eine Person „Ich kümmere mich“ gesagt hat. Ohne On-Call-Tool genügt eine Antwort im Incident-Channel; notieren Sie die Uhrzeit. In Uptimecheck bestätigen Sie den Vorfall in der App oder, mit der Slack-App, per Button in Slack, und die Uhrzeit wird erfasst.
Wiederhergestellt: der erste erfolgreiche Check nach dem Vorfall – zugleich der Moment, in dem die Entwarnung verschickt wird.
Bei Uptimecheck hat jeder Vorfall eine Zeitleiste: wann er begann, wer wann alarmiert wurde, Bestätigungen (auch per Button in Slack, wenn Sie die Slack-App nutzen), Notizen und die Wiederherstellung. MTTA und MTTR werden für Sie berechnet, und der CSV-Export des Berichts liefert pro Monitor die Anzahl der Vorfälle, die Ausfallzeit und den längsten Vorfall für Ihre Tabellenkalkulation. Halten Sie Ihre Erkenntnisse in einem Postmortem fest.
Ein praktischer Hinweis: Durchschnittswerte verbergen Ausreißer. Ein sechsstündiger Vorfall und neun einminütige Aussetzer ergeben im Schnitt etwa 37 Minuten – was keinen von beiden beschreibt. Betrachten Sie neben dem Mittelwert auch den Median und den längsten Vorfall, und gehen Sie die langsamsten Vorfälle einzeln durch.
So verkürzen Sie die Erkennungszeit
Jede Minute prüfen
Das Prüfintervall ist die Obergrenze Ihrer Erkennungszeit. Checks im Minutentakt für alles, was Umsatz bringt oder Kunden bedient, sind die günstigste Einzelmaßnahme zur Senkung der MTTR. Nutzen Sie Uptime-Monitoring im Minutentakt für jede kritische Seite und jeden kritischen Endpunkt.
Prüfen, was kaputtgeht – nicht nur, was lädt
Vorfälle, die das Monitoring nicht sieht, entdecken Kunden – oft Stunden später. Validieren Sie den Inhalt wichtiger Seiten, überwachen Sie die API-Endpunkte, auf die Apps angewiesen sind, und ergänzen Sie geplante Jobs um Heartbeats. Jeder Vorfall, den zuerst ein Kunde meldet, ist eine Lücke in Ihrem Monitoring.
So verkürzen Sie die Bestätigungszeit
Nur bestätigte Alarme senden
Langsame Bestätigung ist meist ein Vertrauensproblem. Wenn die Hälfte der Alarme falsch ist, lernen die Leute abzuwarten. Bestätigen Sie jeden Fehler mit einem zweiten Check, bevor Sie alarmieren, und entfernen Sie Monitore, die alarmieren, ohne dass jemand handeln muss. Unser Leitfaden zum Reduzieren von Fehlalarmen geht ins Detail.
Alarme in den richtigen Kanal leiten
Eine E-Mail um 03:12 Uhr wird um 07:30 Uhr gelesen. Schicken Sie kritische Monitore an einen Kanal, der das Smartphone der Bereitschaft erreicht, und für alle anderen in einen Team-Chat; weniger dringende Monitore bleiben bei E-Mail. In Uptimecheck wählen Sie die Alarmkanäle pro Monitor: E-Mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, Webhooks und Push-Benachrichtigungen aufs Smartphone, in jedem Tarif. Eine Eskalation kann einen Kanal 5 bis 60 Minuten zurückhalten und nur dann alarmieren, wenn der Ausfall noch andauert und niemand ihn bestätigt hat.
Zuständigkeiten klar regeln
Ein Alarm an fünf Personen wird oft von keiner bestätigt. Benennen Sie eine verantwortliche Person pro Dienst und eine Bereitschaft pro Schicht. Alle anderen bekommen die Information, nicht die Verantwortung. Mit den Bereitschaftsplänen von Uptimecheck wechseln sich die Leute ab, mit Ausnahmen für Krankheitstage oder getauschte Dienste, und Push-Alarme erreichen genau die Person, die gerade Bereitschaft hat.
So verkürzen Sie die Reparaturzeit
Runbooks für bekannte Fehler schreiben
Die meisten Vorfälle wiederholen sich. Die Festplatte läuft voll, ein Worker-Pool ist erschöpft, eine Zertifikatserneuerung schlägt fehl. Ein kurzes Runbook pro Monitor macht aus einer halb verschlafenen Fehlersuche eine Checkliste:
Runbook: Checkout liefert 503
1. Server-Dashboard prüfen: CPU, Arbeitsspeicher, Festplatte auf web-01 und web-02.
2. PHP-FPM-Status prüfen: sudo systemctl status php8.3-fpm
3. Wenn die Worker erschöpft sind: sudo systemctl restart php8.3-fpm
4. Nach lang laufenden Jobs suchen: ps aux –sort=-%cpu | head
5. Nach 10 Minuten immer noch Fehler? An den Lead Developer eskalieren.
Legen Sie den Link zum Runbook dort ab, wo der Alarm ankommt, zum Beispiel angepinnt im Incident-Channel – dann ist er nur einen Tipp entfernt.
Ursache und Symptom nebeneinander sehen
Wenn ein Website-Check fehlschlägt, lautet die erste Frage meist, ob dem Server Arbeitsspeicher, CPU oder Festplattenplatz ausgeht. Mit Servermetriken direkt neben den Uptime-Checks wird aus diesem Schritt statt einer SSH-Sitzung ein kurzer Blick.
Rollbacks einfach halten
Viele Vorfälle beginnen mit einem Deployment. Ist ein Rollback ein einziger Befehl, dauert die Wiederherstellung Minuten. Braucht es dafür ein Meeting, dauert sie eine Stunde.
Die Statusseite früh aktualisieren
Eine Statusseite verkürzt nicht den Ausfall selbst, aber den Teil, den Kunden am schlimmsten finden: die Ungewissheit. Außerdem verhindert sie, dass der Support überrannt wird, während das Team das Problem behebt. Eine Statusseite, die mit Ihren Monitoren verbunden ist, zeigt die betroffene Komponente an, sobald der Vorfall eröffnet wird; ergänzen Sie eine kurze Notiz, was Sie gerade tun und wann das nächste Update kommt.
MTBF verbessern
Weniger Vorfälle entstehen, wenn Sie aus den bisherigen lernen. Schreiben Sie nach jedem größeren Vorfall ein Postmortem ohne Schuldzuweisung, einigen Sie sich auf ein oder zwei Maßnahmen und verfolgen Sie diese, bis sie erledigt sind. Innerhalb weniger Monate kehren dieselben Fehler nicht mehr zurück, und die MTBF steigt.
Messen Sie mit echten Zeitstempeln. Testen Sie Uptimecheck 14 Tage kostenlos, ganz ohne Kreditkarte.