Verfügbarkeit ist eine der zentralen Leistungsversprechen im IT-Betrieb. Doch zwischen dem internen Monitoring-Dashboard und dem, was Kunden tatsächlich über den Zustand eines Dienstes wissen, klafft oft eine erhebliche Lücke. Statusseiten schließen diese Lücke – und mit SLA-Metriken auf der Statusseite geht man noch einen Schritt weiter: Man macht Verfügbarkeitszusagen öffentlich messbar.
Das ist keine triviale Entscheidung. Wer SLA-Daten veröffentlicht, setzt sich einem gewissen Druck aus – aber dieser Druck ist produktiv. Er zwingt Teams zu präziser Messung, konsistenter Kommunikation und einer operativen Disziplin, die sich langfristig auszahlt.
Was SLAs auf Statusseiten leisten
Ein Service Level Agreement (SLA) definiert, welche Verfügbarkeit ein Dienst mindestens garantieren soll – typischerweise ausgedrückt als prozentualer Uptime-Wert über einen definierten Zeitraum. 99,9 % bedeuten etwa 8,7 Stunden Ausfallzeit pro Jahr; 99,95 % reduzieren das auf rund 4,4 Stunden.
Wenn dieser Wert nicht nur im Vertrag steht, sondern auf der Statusseite sichtbar und aktuell gemessen wird, entsteht ein qualitativ anderer Vertrauensrahmen:
- Kunden können SLA-Einhaltung selbst überprüfen, ohne auf Anfragen zu warten.
- Interne Teams haben einen klaren Messwert, auf den sich alle Beteiligten beziehen können.
- Die Statusseite wird vom reinen Störungsmelder zum Qualitätsdashboard mit echtem Informationsgehalt.
Welche Metriken gehören auf eine SLA-fähige Statusseite
Uptime-Prozentsatz im Zeitverlauf
Der klassische SLA-Wert: Wie viel Prozent der Zeit war der Dienst innerhalb eines Monats, Quartals oder Jahres verfügbar? Diese Zahl sollte nicht nur als aktueller Wert, sondern auch historisch einsehbar sein – mindestens die letzten 90 Tage, idealerweise 12 Monate. So können Kunden und Nutzer Trends erkennen.
Reaktionszeiten und Incident-Dauer
Uptime allein sagt nicht alles. Wie lange hat es gedauert, bis eine Störung erkannt wurde? Wie lange bis zur Behebung? Diese Metriken – oft als MTTD (Mean Time to Detect) und MTTR (Mean Time to Resolve) bekannt – zeigen die operative Reife eines Teams und sind für Kunden oft relevanter als der reine Uptime-Wert.
Komponentenstatus
Ein einzelner Uptime-Wert für einen komplexen Dienst ist wenig aussagekräftig. Moderne Statusseiten zeigen den Status einzelner Komponenten separat: API, Dashboard, Datenbankcluster, CDN. Kunden können so schnell erkennen, ob ihr spezifischer Nutzungsbereich betroffen ist.
Incident-Häufigkeit und -Muster
Wie oft gab es Störungen im letzten Quartal? Treten sie zu bestimmten Zeiten oder bei bestimmten Komponenten gehäuft auf? Diese Informationen helfen Kunden bei der Planung – und signalisieren gleichzeitig, dass das betreibende Team die eigene Infrastruktur versteht und kontinuierlich verbessert.
Technische Grundlagen: Wie man SLA-Daten misst
Sinnvolle SLA-Metriken auf einer Statusseite erfordern eine externe Monitoring-Infrastruktur. Interne Monitoring-Checks haben einen blinden Fleck: Sie laufen innerhalb derselben Infrastruktur, die sie überwachen. Ein Netzwerkfehler, der Endnutzer betrifft, kann für interne Checks unsichtbar sein.
Externe Prüfpunkte – also Checks, die von verschiedenen geografischen Standorten aus durchgeführt werden – liefern ein realistischeres Bild der tatsächlichen Nutzererfahrung. Multi-Location-Monitoring ist damit keine optionale Ergänzung, sondern Grundvoraussetzung für glaubwürdige SLA-Zahlen.
Zusätzlich braucht man eine klare Definition von „Ausfall": Gilt ein HTTP 500 als Ausfall? Ein Timeout über 5 Sekunden? Ein partieller Ausfall, der nur 10 % der Nutzer betrifft? Diese Definitionen müssen dokumentiert und auf der Statusseite transparent gemacht werden.
Kommunikative Fallstricke vermeiden
Zu viele Nachkommastellen
99,9 % vs. 99,95 % klingt ähnlich, bedeutet aber einen erheblichen Unterschied in der tolerierten Ausfallzeit. Teams sollten SLA-Werte nicht unrealistisch hoch ansetzen und dann bei der ersten größeren Störung unter dem selbst gesetzten Wert bleiben. Besser konservative Zusagen machen und diese verlässlich einhalten.
Unklare Messzeiträume
Wird der SLA-Wert monatlich berechnet? Rollend über 30 Tage? Pro Kalenderquartal? Diese Frage klingt technisch, ist aber für Kunden relevant. Ein Dienst mit einer größeren Störung am Monatsanfang sieht im laufenden Monatsdurchschnitt anders aus als in der rollendem 30-Tage-Betrachtung.
Fehlende Erklärungen bei Abweichungen
Wenn der Uptime-Wert in einem Monat deutlich unter dem SLA liegt, sollte die Statusseite nicht einfach nur die Zahl zeigen – sie sollte auch den Incident verlinken und erklären, was passiert ist und was das Team dagegen unternimmt. Zahlen ohne Kontext wecken Misstrauen; Zahlen mit ehrlicher Erklärung schaffen Vertrauen.
SLA-Transparenz als strategische Entscheidung
Nicht jedes Team und nicht jeder Dienst ist bereit für öffentliche SLA-Metriken. Wer noch keine externe Monitoring-Infrastruktur aufgebaut hat, wer keine klaren Incident-Prozesse etabliert hat und wer intern keine Einigkeit über die SLA-Definition erzielt hat, sollte mit der Veröffentlichung warten.
Aber für Teams, die diese Grundlagen haben, ist SLA-Transparenz ein echter Wettbewerbsvorteil. Sie signalisiert: Wir wissen, wie gut unser Dienst wirklich läuft – und wir haben nichts zu verbergen. Für B2B-Dienste mit Enterprise-Kunden ist das oft ein entscheidender Vertrauensfaktor bei der Anbieterauswahl.
Fazit: Von der reaktiven Störungsseite zum proaktiven Qualitätsdashboard
Eine Statusseite, die nur im Störungsfall aufgerufen wird, verschenkt enormes Potenzial. Mit historischen Uptime-Daten, SLA-Metriken und klarer Komponentenübersicht wird sie zu einem dauerhaft relevanten Kommunikationsinstrument – eines, das Kunden ohne Anfragen informiert und intern als verlässliche Qualitätsmessgröße dient.
Der Weg dorthin erfordert saubere Messmethodik, ehrliche Kommunikation und den Mut, auch schlechte Monate öffentlich zu zeigen. Wer diesen Weg geht, baut langfristig das auf, was im IT-Betrieb schwerer zu erreichen ist als jeder Uptime-Wert: echtes Kundenvertrauen.
Quellen: Google SRE Book – Service Level Objectives; Atlassian – The Incident Response Guide (2025); ITIL 4 Foundation – Service Level Management.
