Incident Metriken, die wirklich zählen – und wie du sie verbesserst

Was sind Incident Metrics?

Incident Metrics sind messbare Datenpunkte, die beschreiben, wie dein Team Incidents erkennt, darauf reagiert und sich davon erholt. Sie machen Muster, Trends und Bottlenecks sichtbar. Eine Metrik allein ist aber nur eine Zahl. Was sie nützlich macht, ist die Beobachtung über Zeit. Eine MTTR von 45 Minuten bedeutet nichts ohne Kontext – eine MTTR, die sich über zwei Quartale von 90 auf 45 Minuten verbessert hat, erzählt dagegen eine Geschichte darüber, was funktioniert.

Die Incident-Timeline: Wo jede Metrik lebt

Jeder Incident folgt derselben grundlegenden Abfolge von Ereignissen, auch wenn die Details unterschiedlich sind:

Darstellung der meist genutzten Incident Metriken

Den längsten Abschnitt der Timeline zu identifizieren ist der erste Schritt zur Verbesserung deiner Werte. Ein Team, das Alerts in 30 Sekunden acknowledget, aber vier Stunden braucht, um das Problem zu lösen, hat ein grundlegend anderes Problem als eines, das Alerts eine Stunde lang verpasst, nach dem ersten Handgriff aber schnell fertig ist.

Mean Time to Detect (MTTD)

MTTD = Summe aller Erkennungszeiten ÷ Anzahl der Incidents

MTTD misst den durchschnittlichen Abstand zwischen dem tatsächlichen Beginn eines Problems und dem Zeitpunkt, an dem dein Monitoring-System es identifiziert. Wenn deine Datenbank um 2:00 Uhr morgens anfängt, Fehler zu werfen, und dein Alert um 2:08 Uhr ausgelöst wird, beträgt die Detection Time für diesen Incident 8 Minuten.

Eine hohe MTTD deutet meist auf eines von zwei Dingen hin: unzureichende Monitoring-Abdeckung oder zu konservativ eingestellte Alert-Schwellenwerte. Manche Teams sehen ihre MTTD auch steigen, wenn sie Systeme mit hoher Komplexität betreiben – Microservices und Multi-Cloud-Setups schaffen mehr Stellen, an denen Probleme sich verstecken können.

Für Incidents in Produktions-Services ist das Ziel bei kritischen Pfaden typischerweise eine Detection Time von unter 5 Minuten. Der Equifax-Datenskandal 2017 blieb 76 Tage unentdeckt. Das ist ein extremes Beispiel dafür, was eine hohe MTTD in der Praxis kosten kann.

Überprüfe deine Monitoring-Abdeckung gegen deine tatsächliche System-Topologie, um die MTTD zu verbessern. Wenn ein Service keinen dedizierten Health Check hat, zeigt sich ein Problem dort erst, wenn Kunden es bemerken – das ist der denkbar schlechteste Weg, einen Incident zu entdecken.

Mean Time to Acknowledge (MTTA)

MTTA = Summe der Zeit von Alert bis Acknowledgment ÷ Anzahl der Incidents

MTTA misst, wie lange es dauert, bis dein Team einen Alert acknowledget, nachdem er ausgelöst wurde. Das ist etwas anderes als Detection: MTTA erfasst, wie schnell ein Mensch den Alert aufnimmt – nicht dein Monitoring-System.

Eine hohe MTTA ist oft ein Zeichen von Alert Fatigue. Wenn Engineers täglich Dutzende minderwertiger Alerts erhalten, gewöhnen sie sich daran, das Rauschen zu ignorieren. Diese Gewohnheit wird gefährlich, wenn ein echter, kritischer Alert eintrifft. Wenn deine MTTA steigt, lohnt es sich zu fragen, wie viele deiner Alerts tatsächlich unmittelbares Handeln erfordern.

Ein weiterer Grund können Lücken in der On-Call-Planung sein. Wenn niemand tatsächlich für einen Alert verantwortlich ist, wird er nicht schnell acknowledget. Die Lösung ist eine gut strukturierte On-Call-Rotation mit klaren Eskalationspfaden – nicht schnellere Engineers.

Mean Time to Resolve (MTTR)

MTTR = Gesamte Ausfallzeit ÷ Anzahl der Incidents

MTTR ist die am häufigsten getrackte Incident-Metrik und auch die am meisten missverstandene – vor allem, weil „MTTR" vier verschiedene Dinge bedeuten kann:

• Mean Time to Recover: von Incident-Beginn bis zur vollständigen Wiederherstellung des Services

• Mean Time to Respond: vom ersten Alert bis zur Lösung (ohne die Detection-Lücke)

• Mean Time to Repair: von dem Moment, an dem Engineers mit der Arbeit beginnen, bis zum Deployment des Fixes

• Mean Time to Resolve: von Incident-Beginn bis zur Behebung der Root Cause (oft länger als die Recovery)

Diese Unterscheidung ist wichtig. Ein Team könnte den Service in 20 Minuten wiederherstellen, aber der zugrundeliegende Bug wird erst zwei Wochen später behoben. Beide Werte sind es wert, getrackt zu werden, auch wenn sie verschiedene Dinge messen.

MTTR ist als North-Star-Metrik durchaus nützlich, verrät dir aber nicht, wo deine Zeit tatsächlich draufgeht. Ein Team mit einer MTTR von 90 Minuten könnte davon 60 Minuten damit verbringen, herauszufinden, was kaputt ist, und nur 30 Minuten mit dem eigentlichen Fix. MTTR verbessert sich oft automatisch, wenn MTTD und MTTA reduziert werden.

Mean Time to Contain (MTTC)

MTTC wird seltener getrackt, kann sich aber lohnen – denn es misst, wie lange es dauert, einen Incident am Ausbreiten zu hindern, nachdem er erkannt wurde. Bei einem Datenbanküberlastungs-Szenario könnte Containment bedeuten, Rate-Limiting einzusetzen oder Kapazität zu erweitern. Bei einem Security-Breach bedeutet es, betroffene Systeme zu isolieren.

Diese Metrik ist besonders wichtig, wenn deine Incidents dazu neigen, einen „Blast Radius" zu haben – also wenn ein kleines Problem zu einem größeren eskaliert, weil das Containment zu langsam war. MTTC separat von MTTR zu tracken hilft dir, solche Muster früh zu erkennen.

Mean Time Between Failures (MTBF)

MTBF = Gesamte Betriebszeit ÷ Anzahl der Failures

MTBF misst die durchschnittliche Zeit zwischen Incidents. Diese Metrik fokussiert auf die Incident-Häufigkeit statt auf die Lösung. Ein Team mit einer guten MTTR, aber einer niedrigen MTBF, ist schnell beim Feuerlöschen – das es ständig selbst anfacht.

Die MTBF zu verbessern erfordert andere Maßnahmen als die MTTR zu verbessern: bessere Post-Incident-Reviews, systematische Beseitigung wiederkehrender Failure-Muster und Investitionen in System-Reliability. Wenn die MTBF steigt, ist das ein Zeichen dafür, dass deine Präventionsarbeit Früchte trägt.

Incident-Volumen und Severity-Verteilung

Die rohe Incident-Anzahl ist eine einfache, aber aufschlussreiche Metrik. Wenn das Incident-Volumen Monat für Monat steigt, läuft strukturell etwas falsch – unabhängig davon, wie gut deine MTTR aussieht. Tracking nach Severity-Level fügt mehr Nuance hinzu: Ein Anstieg bei SEV-3-Incidents ist handhabbar, ein Anstieg bei SEV-1 ist ein ernstes Problem.

Die Severity-Verteilung deckt auch auf, ob deine Severity-Level konsistent angewendet werden. Wenn 80 % deiner Incidents SEV-2 sind, nutzt dein Team wahrscheinlich beide Enden der Skala zu wenig.

SLA-Compliance-Rate

Wenn dein Service definierte SLAs oder SLOs hat, schließt das Tracking, wie viel Prozent der Incidents innerhalb dieser Zeitrahmen gelöst werden, den Kreis zwischen internen Metriken und externen Commitments. Eine gute MTTR bedeutet wenig, wenn du SLAs verfehlst. In diesem Fall sind entweder die SLA-Ziele zu eng gesteckt – oder die MTTR-Zahlen werden von einem anderen Startpunkt aus gemessen als die SLA-Uhr.

Der häufigste Fehler beim Umgang mit Incident Metrics

Nur die MTTR zu tracken und als einzige Wahrheitsquelle zu behandeln kann dazu führen, dass Incidents vorschnell geschlossen werden, auch wenn das eigentliche Problem noch nicht behoben ist. Engineers lernen, Tickets zu schließen, um die Metrik zu treffen, und beobachten dann, wie derselbe Incident zwei Stunden später wieder aufgeht.

Die Lösung ist ein ausgewogenes Portfolio an Metriken. Eine hohe MTTR mit niedriger MTTA deutet auf ein Resolution-Problem hin. Eine hohe MTTR mit hoher MTTA legt ein On-Call- oder Alerting-Problem nahe. Eine niedrige MTTR, aber niedrige MTBF bedeutet, dass du Incidents schnell löst, aber nicht verhinderst. Jede Kombination erzählt eine andere Geschichte und erfordert eine andere Intervention.

Sinnvolle Benchmarks setzen

Vergleiche deine MTTR nicht mit Branchen-Durchschnittswerten aus Vendor-Reports. Diese Zahlen aggregieren Teams unterschiedlichster Größe, Systemkomplexitäten und Incident-Definitionen zu einer einzigen Zahl – die im Grunde bedeutungslos ist. Incident Metrics sind nicht universell übertragbar.

Benchmark stattdessen gegen dich selbst. Ermittle eine Baseline im ersten Monat, setze dir ein konkretes Verbesserungsziel für Monat drei und ein noch höheres für Monat sechs. High-Performance-Teams, die kritische Incidents bearbeiten, streben typischerweise nach:

• Severity 1: Lösung in unter 1 Stunde

• Severity 2: Lösung in unter 4 Stunden

• Severity 3: Lösung in unter 24 Stunden

Das sind Zielwerte, keine Standards. Was zählt, ist die Verbesserung in die richtige Richtung – ausgehend von deiner eigenen Baseline.

Incident Metrics in der Praxis tracken

Metriken manuell aus Spreadsheets zu berechnen ist möglich, aber mühsam und fehleranfällig, wenn Teams Timestamps unterschiedlich erfassen. Die meisten Incident-Management-Plattformen tracken sie automatisch anhand der Timestamps, die während des Incident-Lifecycles aufgezeichnet werden: wann der Alert ausgelöst wurde, wann der erste Responder acknowledget hat, wann der Incident als gelöst markiert wurde.

Incidite erfasst die vollständige Incident-Timeline automatisch, sodass MTTA und MTTR aus den Quelldaten berechnet werden – und nicht aus dem Gedächtnis rekonstruiert. Diese Konsistenz ist wichtig, wenn du echte Trends identifizieren willst statt statistisches Rauschen durch inkonsistente Messung.

Incident Metrics werden deine Incidents nicht lösen. Aber sie zeigen dir genau, wo dein Response-Prozess Arbeit braucht. Tracke das vollständige Set, vergleiche gegen deine eigene Baseline und behandle eine steigende MTBF als die Metrik, die zeigt, dass deine Reliability-Kultur tatsächlich funktioniert.

Wenn du einen Ausgangspunkt auf der Prozessseite suchst, zeigt unser Guide zum Incident Management, wie du deinen Response-Workflow von A bis Z strukturierst.