Was ist MTTR (Mean Time to Repair)?
Die Mean Time to Repair (MTTR, deutsch: mittlere Reparaturzeit) misst die durchschnittliche Zeit, die benötigt wird, um ein ausgefallenes System wieder in den Betriebszustand zu versetzen. Die Zeitmessung beginnt mit der Störungsmeldung und endet, wenn das System vollständig wiederhergestellt ist.
Im CX-Kontext ist MTTR direkt geschäftsrelevant: Wenn die Contact-Center-Plattform ausfällt, können Kunden weder anrufen noch chatten. Jede Minute Ausfallzeit bedeutet verpasste Kundenanfragen, steigende Abandonment Rate und potenziell verlorene Kunden. Eine niedrige MTTR begrenzt den Schaden und signalisiert Kunden, dass Probleme schnell gelöst werden.
MTTR wird häufig in SLA-Vereinbarungen (SLA Compliance Rate) als Zielgröße definiert, besonders in der Telekommunikation, bei Cloud-Anbietern und im IT-Outsourcing.
MTTR-Varianten
Mean Time to Repair bezeichnet die reine Reparaturzeit: vom Beginn der Fehlerdiagnose bis zur Wiederherstellung des Systems.
Mean Time to Restore/Recover ist die breitere Definition und umfasst die gesamte Ausfallzeit inklusive Erkennung, Diagnose, Reparatur und Verifizierung. In der Praxis wird diese Definition häufiger verwendet.
Mean Time to Respond misst nur die Reaktionszeit bis zur ersten qualifizierten Bearbeitung. Nicht zu verwechseln mit der vollständigen Wiederherstellung.
Alle drei Varianten werden als MTTR abgekürzt, weshalb die exakte Definition in SLA-Vereinbarungen immer explizit festgelegt werden sollte.
Wie berechnet man MTTR?
Rechenbeispiel
Ein IT-Team bearbeitet in einem Monat 6 kritische Incidents. Die einzelnen Reparaturzeiten betragen 45 Min, 2 h, 1,5 h, 30 Min, 3 h und 1 h. Die Gesamtreparaturzeit beträgt 8 Stunden 45 Minuten (8,75 h).
Eine MTTR von 1 Stunde und 27 Minuten liegt im akzeptablen Bereich für kritische IT-Systeme. Das Team sollte analysieren, warum einzelne Incidents (3 h) deutlich über dem Durchschnitt lagen.
MTTR-Benchmarks
| Severity | Ziel (Best Practice) | Akzeptabel | Kritisch |
|---|---|---|---|
| Severity 1 (Totalausfall) | < 1 h | 1–4 h | > 4 h |
| Severity 2 (Teilausfall) | < 4 h | 4–8 h | > 8 h |
| Severity 3 (Eingeschränkt) | < 8 h | 8–24 h | > 24 h |
| Severity 4 (Gering) | < 24 h | 24–72 h | > 72 h |
MTTR nach Branche
| Branche | Typische MTTR (Sev 1) | Kontext |
|---|---|---|
| Telekommunikation | 1–2 h | Regulatorische Vorgaben, 24/7-Betrieb |
| Finanzdienstleistung | 30 Min–1 h | Hohe Kosten pro Ausfallminute |
| E-Commerce | 1–2 h | Direkte Umsatzverluste während Ausfall |
| SaaS-Anbieter | 30 Min–2 h | SLA-gebunden, Uptime-Garantien |
| Fertigungsindustrie | 2–4 h | Abhängig von Ersatzteillogistik |
Laut einer Studie von Atlassian kostet IT-Ausfallzeit Unternehmen durchschnittlich 5.600 USD pro Minute (Atlassian). Für große Unternehmen kann dieser Betrag deutlich höher liegen. Eine Verbesserung der MTTR um 30 Minuten kann dadurch pro Incident mehrere Hunderttausend Euro einsparen.
Quellen: Atlassian Incident Management, PagerDuty State of Digital Operations
MTTR senken
Runbooks und Standardprozesse. Dokumentierte Schritt-für-Schritt-Anleitungen für die häufigsten Fehlerfälle. Reduzieren die Diagnosezeit erheblich, besonders bei weniger erfahrenen Team-Mitgliedern.
Monitoring und automatisierte Alerts. Je schneller ein Ausfall erkannt wird, desto früher beginnt die Reparatur. Proaktives Monitoring kann die Erkennungszeit von Minuten auf Sekunden reduzieren.
On-Call-Rotation und Eskalationspfade. Klare Verantwortlichkeiten und schnelle Eskalation vermeiden Zeitverlust durch Zuständigkeitsklärung. Tools wie PagerDuty oder OpsGenie automatisieren die Alarmierung.
Post-Incident Reviews. Nach jedem Incident systematisch analysieren: Was hat die Reparatur verzögert? Welche Informationen fehlten? Lessons Learned in Runbooks einpflegen.
Redundanz und Failover. Automatisches Failover auf Backup-Systeme verkürzt die effektive Ausfallzeit auf Sekunden, auch wenn die eigentliche Reparatur länger dauert. Für geschäftskritische Contact-Center-Systeme ist das der wirkungsvollste Hebel.
MTTR vs. MTBF vs. Resolution Time
| Kennzahl | Was sie misst | Perspektive | Typisches Ziel |
|---|---|---|---|
| MTTR | Reparaturzeit nach Ausfall | IT-Betrieb | < 1 h (Sev 1) |
| MTBF | Betriebszeit zwischen Ausfällen | Zuverlässigkeit | So hoch wie möglich |
| Resolution Time | Lösungszeit für Kundenanliegens | Kundenservice | < 24 h |
MTTR und MTBF bilden zusammen das Verfügbarkeitsbild eines Systems. Eine hohe MTBF (seltene Ausfälle) bei niedriger MTTR (schnelle Reparatur) ergibt maximale Verfügbarkeit. Resolution Time operiert auf einer anderen Ebene: Sie misst die Kundenerfahrung bei der Problemlösung, unabhängig davon, ob ein Systemausfall die Ursache war.
Pro und Kontra
Pro
- +Direkt messbarer Indikator für die Effizienz des IT-Supports
- +Standardkennzahl in SLA-Vereinbarungen und ITIL-Frameworks
- +Ermöglicht Vergleich zwischen Teams, Zeiträumen und Systemen
- +Deckt Schwachstellen im Incident-Management-Prozess auf
Kontra
- –Durchschnittswert verbirgt Ausreißer (ein Incident mit 12 h verzerrt den Schnitt)
- –Unterschiedliche Definitionen (Repair vs. Restore vs. Respond) erschweren Vergleichbarkeit
- –Berücksichtigt nicht die Schwere oder geschäftliche Auswirkung des Ausfalls
- –Kann zu Fehlanreizen führen: schnelle Workarounds statt nachhaltiger Reparaturen
Einfluss von KI auf MTTR
KI senkt die MTTR auf mehreren Ebenen. Automatisierte Fehlerdiagnose durch KI-Systeme kann die Diagnosezeit um 50–70 % reduzieren, indem sie Logs, Metriken und historische Incidents in Sekunden korreliert (Gartner, AIOps Market Guide).
KI-gestützte Runbook-Automation führt Standardreparaturen automatisch aus, etwa Dienste neu starten, Failover auslösen oder Ressourcen skalieren. Für wiederkehrende Incident-Typen kann die MTTR so auf unter eine Minute sinken. Im Contact-Center-Bereich bedeutet das: Die Telefonanlage erkennt ein Problem selbst, löst ein Failover aus und informiert das Team, während die Kunden vom Ausfall nichts bemerken.