MTTD (Mean Time to Detect) ist die durchschnittliche Zeit zwischen dem tatsächlichen Beginn eines Incidents und seiner Erkennung durch einen Alert, einen Monitoring-Check oder eine Meldung. Die Kennzahl zeigt, wie schnell Monitoring und Alerting echte Probleme sichtbar machen, und bildet die erste Phase der gesamten Reaktionszeit auf Incidents.
Was ist MTTD (Mean Time to Detect)?
MTTD (Mean Time to Detect) beschreibt die durchschnittliche Zeit, bis ein Problem bemerkt wird. Die Uhr startet, sobald ein Fehler das System beeinträchtigt, etwa wenn die Fehlerrate nach einem fehlerhaften Deployment steigt. Sie stoppt, wenn der Incident erkannt wird: Ein Alert feuert, ein synthetischer Check schlägt fehl oder ein Kunde eröffnet ein Ticket. Die MTTD ist die früheste Phase im Incident-Lebenszyklus und bildet die Untergrenze für alles Weitere. Was niemand sieht, kann weder analysiert noch behoben werden.
Die MTTD wird meist zusammen mit der MTTR betrachtet. Die Erkennungszeit ist Teil der gesamten Behebungszeit. Eine schnellere Erkennung verkürzt also den ganzen Incident, oft mit weniger Aufwand als eine schnellere Behebung.
MTTD berechnen
Die Formel ist einfach: Summieren Sie die Erkennungszeiten aller Incidents in einem Zeitraum und teilen Sie durch die Anzahl der Incidents.
MTTD = Summe(erkannt_um - begonnen_um) / Anzahl_IncidentsEin illustratives Beispiel: In einem Monat hat ein Team vier Incidents mit Erkennungszeiten von 3, 7, 12 und 38 Minuten. Die MTTD beträgt (3 + 7 + 12 + 38) / 4 = 15 Minuten. Auffällig ist, dass die eine langsame Erkennung den Mittelwert dominiert. Deshalb berichten viele Teams zusätzlich den Median oder ein hohes Perzentil und prüfen Ausreißer einzeln.
Schwierig ist nicht die Rechnung, sondern der Zeitstempel. erkannt_um lässt sich direkt aus Alert oder Ticket übernehmen. begonnen_um wird meist nachträglich im Postmortem anhand der Telemetrie rekonstruiert: Wann wichen Fehlerrate, Latenz oder Sättigung erstmals vom Normalzustand ab?
Warum die MTTD wichtig ist
- Auswirkungen auf Nutzer wachsen unbemerkt. Jede Minute vor der Erkennung bedeutet abgebrochene Bestellungen oder langsame Seiten, um die sich niemand kümmert.
- Kunden sollten nicht Ihr Monitoring sein. Werden Incidents regelmäßig zuerst von Nutzern gemeldet, hat die Überwachung Lücken.
- Sie macht Monitoring-Qualität messbar. Eine hohe MTTD weist auf fehlende Signale, zu lockere Schwellenwerte oder Alerts ohne Empfänger hin.
- Sie schützt das Error Budget. Eine langsame Erkennung lässt einen Ausfall Zuverlässigkeitsziele aufzehren, bevor jemand reagiert.
MTTD im Incident-Lebenszyklus
Die MTTD ist eine von mehreren zeitbasierten Incident-Kennzahlen, die gemeinsam beschreiben, wie ein Team reagiert. Getrennt betrachtet zeigen sie, wo tatsächlich Zeit verloren geht:
| Kennzahl | Misst die Zeit von | Wird vor allem beeinflusst durch |
|---|---|---|
| MTTD | Beginn des Incidents bis zur Erkennung | Signalabdeckung, Alert-Regeln, synthetische Checks |
| MTTA (Mean Time to Acknowledge) | Alert bis zur Übernahme durch eine Person | Routing, Rufbereitschaft, Benachrichtigungskanäle |
| MTTR (Mean Time to Resolve oder Restore) | Beginn oder Erkennung bis zur Wiederherstellung | Diagnosewerkzeuge, Runbooks, Rollback-Fähigkeit |
| MTBF (Mean Time Between Failures) | Ein Ausfall bis zum nächsten | Architekturqualität, Tests, Change Management |
Ein Team mit kurzer MTTR, aber langer MTTD behebt Probleme schnell, sobald es davon weiß, erfährt aber zu spät davon. Der Hebel liegt dann im Monitoring, nicht in der Fehlersuche. Segmentieren Sie die MTTD zusätzlich nach Schweregrad: Die Erkennung eines Totalausfalls und die Erkennung einer langsamen, teilweisen Verschlechterung sind sehr unterschiedliche Aufgaben und verdienen getrennte Ziele. Gerade schleichende Degradationen bleiben ohne Burn-Rate- oder Baseline-Alerts oft stundenlang unbemerkt.
So senken Sie die MTTD
- Alarmieren Sie auf Symptome, die Nutzer spüren. Fehlerrate, Latenz und Verfügbarkeit pro Service, wie in den Golden Signals beschrieben, erfassen mehr Incidents als Host-Metriken.
- Nutzen Sie SLO-Burn-Rate-Alerts. Sie reagieren schnell auf schwere Probleme, erkennen aber auch schleichende Verschlechterungen, ohne bei jedem Ausschlag zu feuern.
- Ergänzen Sie Prüfungen von außen. Synthetisches Monitoring erkennt defekte Login- oder Checkout-Abläufe auch bei wenig Traffic, etwa nachts.
- Verwenden Sie Baselines statt statischer Schwellen für Metriken mit Tages- oder Wochenmustern, damit Abweichungen sofort auffallen.
- Reduzieren Sie Rauschen. Zu viele Alerts erhöhen die MTTD, weil echte Warnungen untergehen. Weniger Alert Fatigue ist eine direkte Verbesserung der Erkennung.
- Markieren Sie Deployments. Wenn Fehler einem Release zugeordnet werden, werden Regressionen innerhalb von Minuten sichtbar.
Häufige Fehler
- Die Zeit vom Alert bis zur Bestätigung als MTTD zu messen. Das ist die Time to Acknowledge, eine andere und spätere Phase.
- Von Kunden gemeldete Incidents auszuklammern und damit genau die Erkennungslücken zu verstecken, die Sie finden wollen.
- MTTD-Werte zwischen Teams mit unterschiedlichen Incident-Definitionen oder Schweregrad-Skalen zu vergleichen.
- Die MTTD zu optimieren, indem alle Schwellen gesenkt werden. Das erkauft Geschwindigkeit mit einer Flut von Fehlalarmen.
- Sich nur auf Mittelwerte zu verlassen, obwohl pro Quartal nur wenige Incidents auftreten.
Wie Obseria hilft
Obseria wertet SLOs mit Multi-Window-Burn-Rate-Alerts aus und wendet Baseline-basierte Anomalie-Erkennung auf Metriken, Traces und Logs an, damit Abweichungen früh sichtbar werden. Synthetische Checks überwachen kritische Nutzerpfade von außen. Erkennungs- und Bestätigungszeitpunkte werden im Incident Management festgehalten. So wird die MTTD pro Service und Schweregrad messbar statt geschätzt.