Ein SLI (Service Level Indicator) ist eine Messgröße dafür, wie sich Ihr Dienst verhält, etwa der Anteil erfolgreicher Anfragen. Ein SLO (Service Level Objective) ist das interne Ziel für diese Messgröße, etwa 99,9 % erfolgreiche Checks über 30 Tage. Ein SLA (Service Level Agreement) ist das Versprechen, das Sie Kunden geben – meist mit einem niedrigeren Ziel als das SLO und einer Konsequenz wie einer Gutschrift, wenn Sie es verfehlen. Der Indikator ist, was Sie messen, das Ziel ist, was Sie anstreben, und die Vereinbarung ist, was Sie unterschreiben.
Dieser Leitfaden erklärt jeden Begriff mit Beispielen, zeigt, was Uptime-Prozentwerte in Minuten bedeuten, und führt Sie durch die Auswahl von Indikatoren für eine Website oder API, die Entscheidung, was als Downtime zählt, und das Formulieren eines SLA, das Kunden verstehen.
Die drei Begriffe einfach erklärt
SLI: die Messgröße
Ein Service Level Indicator ist eine Zahl, die Sie aus echten Daten berechnen können. Fast immer ist es ein Verhältnis: gute Ereignisse geteilt durch alle Ereignisse. Bei einer Website könnte das der Anteil der Uptime-Checks sein, die die erwartete Antwort geliefert haben. Bei einer API der Anteil der Anfragen, die in unter 500 Millisekunden mit einem Status außerhalb von 5xx geantwortet haben. Ein SLI hat kein Ziel. Er sagt einfach, was passiert ist.
SLO: das Ziel
Ein Service Level Objective versieht einen SLI mit einem Ziel und einem Zeitfenster. „99,9 % der Checks auf den Checkout sind erfolgreich, gemessen über rollierende 30 Tage“ ist ein SLO. Es ist ein internes Werkzeug. Es zeigt dem Team, wann die Zuverlässigkeit gut genug ist, um weiter Features auszuliefern, und wann es Zeit ist, das Tempo zu drosseln und Probleme zu beheben.
SLA: der Vertrag
Ein Service Level Agreement ist das externe Versprechen, festgehalten in einem Vertrag oder den Nutzungsbedingungen. Es nennt den Dienst, das Ziel, wie gemessen wird, was ausgenommen ist und was der Kunde bekommt, wenn Sie es verfehlen. Nicht jeder Dienst braucht ein SLA, aber jedes SLA braucht ein SLO dahinter – sonst haben Sie keine Frühwarnung, dass Sie es gleich brechen.
Wie SLIs, SLOs und SLAs zusammenhängen
Stellen Sie sie sich als Ebenen vor. Der SLI ist das Rohsignal. Das SLO ist eine strengere interne Linie auf diesem Signal. Das SLA ist eine lockerere externe Linie auf demselben Signal. Ein typisches Setup für ein SaaS-Produkt sieht so aus (Beispielwerte):
SLI: Anteil der minütlichen Checks auf app.lumenanalytics.io, die Status 200 liefern und den Titel des Dashboards enthalten.
SLO: 99,95 % pro Kalendermonat.
SLA: 99,9 % pro Kalendermonat, mit Gutschrift bei Verfehlung.
Der Abstand zwischen 99,95 % und 99,9 % ist der Sicherheitspuffer. Sieht das Team das SLO in der zweiten Woche wegrutschen, bleibt noch Zeit zu handeln, bevor das vertragliche Versprechen gefährdet ist.
Uptime-Prozentwerte in Minuten
Uptime-Ziele wirken auf dem Papier nah beieinander, aber jede zusätzliche Neun teilt die erlaubte Downtime durch zehn. Die folgende Tabelle rechnet mit einem durchschnittlichen Monat (ein Jahr mit 365,25 Tagen geteilt durch 12), genau wie der Uptime-Rechner; ein 30-Tage-Monat erlaubt etwas weniger.
Uptime-ZielErlaubte Downtime pro MonatErlaubte Downtime pro Jahr99 %7 h 18 min 18 s3 Tage 15 h 39 min 36 s99,5 %3 h 39 min 9 s1 Tag 19 h 49 min 48 s99,9 min 49 s8 h 45 min 57 s99,95 min 54 s4 h 22 min 58 s99,99 %4 min 22 s52 min 35 s99,999 s5 min 15 s
Daraus folgen zwei praktische Konsequenzen. Erstens muss Ihr Monitoring die Downtime, die Sie versprechen, überhaupt sehen können. Mit Checks alle fünf Minuten lässt sich ein monatliches Ziel von 99,99 % nicht ehrlich messen, weil ein einziger übersehener Ausfall das ganze Budget aufbrauchen könnte. Zweitens lässt jedes Ziel über 99,9 % kaum Raum für manuelle Reaktion. Bei 99,99 % ist mit einem langsam bearbeiteten nächtlichen Vorfall der Monat gelaufen.
Error Budgets: aus dem SLO Entscheidungen machen
Ein Error Budget ist die Menge an Fehlern, die Ihr SLO zulässt. Bei einem monatlichen SLO von 99,9 % beträgt das Budget 0,1 % des Monats, in einem durchschnittlichen Monat etwa 43 Minuten und 49 Sekunden (in einem 30-Tage-Monat 43 Minuten und 12 Sekunden). Jeder Vorfall verbraucht einen Teil davon.
Das Budget macht Zuverlässigkeit zu einer gemeinsamen Entscheidung statt zu einem Streitpunkt. Eine einfache Regel, die viele Teams nutzen:
Mehr als die Hälfte des Budgets übrig: normal ausliefern.
Weniger als die Hälfte übrig: riskante Deploys prüfen, Datenbankänderungen von einer zweiten Person absegnen lassen.
Budget aufgebraucht: Feature-Releases für diesen Dienst pausieren und an den Ursachen der letzten Vorfälle arbeiten, bis das Zeitfenster neu beginnt.
Ein Beispiel: harborlabs.dev hat für seine öffentliche API ein monatliches SLO von 99,9 %. Am 9. verursacht ein fehlerhafter Deploy 18 Minuten Fehler. Am 20. kommen durch ein Zertifikatsproblem 9 weitere hinzu. Damit sind 27 von 43 Minuten verbraucht, und es bleiben noch zehn Tage. Das Team verschiebt die nächste Schema-Migration auf den neuen Monat, weil ein weiterer Vorfall derselben Größe das Ziel verfehlen würde.
SLIs für eine Website oder API auswählen
Gute SLIs beschreiben, was Nutzer erleben, nicht was Ihre Server spüren. CPU bei 90 % ist kein SLI. Ein fehlschlagender Checkout schon. Beginnen Sie mit zwei oder drei Indikatoren pro Dienst:
Verfügbarkeit: der Anteil der Checks oder Anfragen, die erfolgreich sind. Bei einer Website sollte „erfolgreich“ den richtigen Statuscode und den richtigen Inhalt bedeuten, nicht nur irgendeine Antwort.
Latenz: der Anteil der Anfragen, die schneller als ein Schwellenwert antworten, zum Beispiel 95 % unter 800 ms. Mit einem Anteil lässt sich leichter arbeiten als mit einem Durchschnitt, der langsame Ausreißer verdeckt.
Korrektheit: bei APIs der Anteil der Antworten, die die erwarteten Felder enthalten. Ein 200 mit leerem Body ist kein Erfolg.
Messen Sie die Wege, die zählen. Bei einem Shop wie northwind.shop sind das der Checkout und die Produktseiten, nicht nur die gecachte Startseite. Bei einer API sind es die Endpunkte, gegen die Kunden integrieren, idealerweise über einen Health-Check-Endpunkt, der Datenbank und andere Abhängigkeiten prüft. Ein API-Monitor, der den Response-Body validiert, macht diesen Endpunkt zu einem SLI, dem Sie vertrauen können.
Was in die Uptime einfließt
Bei den meisten Streitigkeiten um SLAs geht es nicht um die Zahl, sondern darum, was zählt. Klären Sie diese Punkte, bevor Sie ein Ziel veröffentlichen:
Geplante Wartung. Viele SLAs nehmen vorab angekündigte Wartungen aus, etwa mit 72 Stunden Vorlauf und höchstens vier Stunden pro Monat. Wenn Sie sie ausnehmen, legen Sie fest, wie sie angekündigt wird, und setzen Sie eine Obergrenze – sonst wird „Wartung“ zum Schlupfloch.
Teilausfälle. Ist der Dienst down, wenn der Login funktioniert, aber der Checkout nicht? Legen Sie fest, welche Komponenten abgedeckt sind und ob der Ausfall einer Komponente als Downtime für das Ganze zählt.
Eingeschränkte Leistung. Entscheiden Sie, ob Antworten über einem Schwellenwert als Fehler zählen. Braucht eine Seite 30 Sekunden, halten Nutzer sie für ausgefallen.
Ursachen außerhalb Ihres Einflusses. Netzwerkprobleme auf Kundenseite, Missbrauch und höhere Gewalt werden üblicherweise ausgenommen. Ihr eigener Hosting-Anbieter meist nicht – Kunden haben den Dienst bei Ihnen gekauft.
Mindestdauer. Manche SLAs zählen nur Ausfälle, die länger als eine Minute dauern oder von mehr als einem Check bestätigt werden – so, wie auch das Monitoring Fehler bestätigt.
Intern ist es oft sinnvoll, geplante Wartung in Ihr SLO einzurechnen, auch wenn das SLA sie ausnimmt. Nutzer konnten den Dienst trotzdem nicht erreichen, und das SLO soll ihre Erfahrung widerspiegeln.
Ein SLA für Kunden formulieren
Ein gutes SLA ist kurz und konkret. Es sollte sechs Fragen beantworten: welcher Dienst, welches Ziel, wie gemessen, über welchen Zeitraum, mit welchen Ausnahmen und was passiert, wenn Sie es verfehlen. Hier ist eine Beispielklausel, die Sie anpassen können:
Dienst: die Webanwendung von Lumen Analytics unter app.lumenanalytics.io
und die öffentliche API unter api.lumenanalytics.io.
Ziel: 99,9 % Verfügbarkeit pro Monat.
Messung: Die Verfügbarkeit wird durch externe Checks jede Minute gemessen.
Eine Minute gilt als nicht verfügbar, wenn der Dienst einen Fehler (5xx)
oder keine Antwort liefert, bestätigt durch einen zweiten Check.
Ausnahmen: geplante Wartung, die mindestens 72 Stunden im Voraus auf
unserer Statusseite angekündigt wird (max. 4 Stunden pro Monat); Probleme,
die durch das Netzwerk oder die Systeme des Kunden verursacht werden.
Gutschriften: unter 99,9 %: 10 % der Monatsgebühr.
unter 99,0 %: 25 % der Monatsgebühr.
Kunden beantragen Gutschriften innerhalb von 30 Tagen nach Monatsende.
Setzen Sie das SLA unter dem an, was Sie tatsächlich erreichen. Zeigt Ihr Monitoring-Verlauf 99,97 % über das letzte Jahr, sind 99,9 % ein realistisches Versprechen. Wer 99,99 % verspricht, weil es besser klingt, macht jeden Vorfall zu einem Vertragsproblem.
Halten Sie Gutschriften verhältnismäßig und den Antragsweg einfach. Kunden wollen selten das Geld. Sie wollen sehen, dass Sie das Versprechen ernst nehmen und ehrlich messen.
Messen mit externem Monitoring
Ihre eigenen Logs können keinen Ausfall messen, bei dem die Anfrage Ihren Server nie erreicht hat. DNS-Fehler, abgelaufene Zertifikate, Netzwerkprobleme und ein abgestürzter Load Balancer lassen interne Metriken ruhig. Deshalb sollte die SLA-Messung von außen kommen, auf demselben Weg, auf dem Kunden Sie erreichen. Wenn das Thema neu für Sie ist, beginnen Sie mit Was Uptime-Monitoring ist und wie es funktioniert.
Ein solides Setup für SLA-Reporting:
Jede Minute prüfen. Das Intervall bestimmt die Auflösung Ihrer Messung.
Jeden Fehler mit einem zweiten Check bestätigen. So landet ein einzelner Aussetzer im Netzwerk nicht in Ihren Downtime-Zahlen.
Inhalte validieren. Prüfen Sie auf ein Wort oder Feld, das nur erscheint, wenn der Dienst funktioniert.
Den Verlauf aufbewahren. Sie brauchen Beginn und Ende jedes Vorfalls für jeden Monat, über den Sie berichten.
Veröffentlichen. Eine Statusseite mit Uptime-Verlauf zeigt Kunden dieselben Zahlen, die Sie sehen.
Uptimecheck deckt das ab mit Uptime-Monitoring bis zu jede Minute aus Stockholm, London und New York, SLA-Berichten pro Monitor für den aktuellen oder letzten Monat oder die letzten 7, 30 oder 90 Tage gegen Ihr Ziel, CSV-Export für den monatlichen SLA-Nachweis sowie wöchentlichen und monatlichen E-Mail-Berichten. Eine Statusseite, die mit denselben Monitoren verbunden ist, zeigt Kunden den Uptime-Verlauf hinter Ihrem Versprechen.
Uptime ist nur eine Seite der Zuverlässigkeit. Wie schnell Sie Vorfälle erkennen und beheben, entscheidet, wie viel Budget jeder einzelne verbraucht; mehr zur Reaktionsseite lesen Sie in MTTR, MTTA und MTBF erklärt.
Checkliste: SLIs, SLOs und ein SLA festlegen
Listen Sie die User Journeys auf, die zählen: Login, Checkout, die zentrale API.
Definieren Sie pro Journey einen Verfügbarkeits-SLI und, wo es darauf ankommt, einen Latenz-SLI.
Messen Sie ein bis zwei Monate, bevor Sie Ziele festlegen.
Setzen Sie das SLO etwas unter dem an, was Sie heute erreichen, und einigen Sie sich auf eine Error-Budget-Regel.
Setzen Sie das SLA unter dem SLO an, mit klaren Ausnahmen und verhältnismäßigen Gutschriften.
Messen Sie extern jede Minute und prüfen Sie die Zahlen monatlich.
Messen Sie die Uptime, die Sie versprechen, dort, wo Ihre Kunden stehen. Testen Sie Uptimecheck 14 Tage kostenlos, keine Kreditkarte erforderlich.