Ein SLI (Service Level Indicator) ist eine Messgröße, etwa der Anteil erfolgreicher Anfragen. Ein SLO (Service Level Objective) ist das interne Ziel für diese Größe, etwa 99,9 % in 30 Tagen. Ein SLA (Service Level Agreement) ist die vertragliche Zusage an Kunden, meist mit Folgen wie Gutschriften, wenn sie verfehlt wird. Das SLO liegt üblicherweise strenger als das SLA.
Das Wichtigste in Kürze
- SLI = Messung, SLO = Ziel, SLA = Vertrag. Erst die Messung macht ein Ziel überprüfbar, erst der Vertrag macht es einklagbar.
- Das Fehlerbudget ist die erlaubte Abweichung: Bei 99,9 % in 30 Tagen sind es rund 43 Minuten.
- Ein SLO ohne klare Messmethode (Prüfziel, Intervall, Erfolgskriterium, Wartungsregel) ist wertlos.
- Ein Hoster-SLA sagt nichts über die Verfügbarkeit Ihrer Website; Abhängigkeiten in Reihe multiplizieren sich.
- SLA-Gutschriften sind meist klein im Vergleich zum Schaden; sie ersetzen keine Vorsorge.
Was bedeuten SLA, SLO und SLI?
Die drei Abkürzungen stammen aus dem Betrieb von Online-Diensten und beschreiben aufeinander aufbauende Ebenen. Am einfachsten merken Sie sich die Reihenfolge messen, anpeilen, zusagen:
- SLI – Service Level Indicator: Eine konkrete, messbare Kennzahl für die Qualität eines Dienstes. Beispiel: „Anteil der Prüfungen, die innerhalb von 2 Sekunden mit Status 200 beantwortet wurden“.
- SLO – Service Level Objective: Ein Zielwert für ein SLI über einen Zeitraum. Beispiel: „Mindestens 99,9 % der Prüfungen sind in 30 Tagen erfolgreich“.
- SLA – Service Level Agreement: Eine Vereinbarung mit Kunden oder Auftraggebern, die Leistungen, Messweise und Folgen bei Nichterfüllung festlegt, zum Beispiel Gutschriften oder Sonderkündigungsrechte.
Das Google-SRE-Buch (siehe Quellen) beschreibt diese Begriffe als Grundlage für die Steuerung von Zuverlässigkeit. Wesentlich ist die Trennung: Ein SLO ist ein internes Steuerungsinstrument, mit dem ein Team entscheidet, wie viel Risiko es eingehen darf. Ein SLA ist ein Rechtsdokument mit Rechtsfolgen. Weil man beim SLA nicht jede Schwankung riskieren will, setzt man das SLO strenger an: Wer Kunden 99,5 % zusagt, peilt intern 99,9 % an und hat damit Spielraum.
Für Betreiber kleiner und mittlerer Websites sind SLA/SLO/SLI keine Konzernthemen. Sobald Sie als Agentur Kunden Verfügbarkeit versprechen, als Shop-Betreiber einen Hoster vergleichen oder intern festlegen wollen, ab wann eine Störung „zu viel“ ist, brauchen Sie genau diese Begriffe. Die Grundlagen der Kennzahl selbst finden Sie in Was bedeutet Uptime?.
Worin unterscheiden sich SLA, SLO und SLI konkret?
| SLI | SLO | SLA | |
|---|---|---|---|
| Frage | Wie gut ist der Dienst gerade? | Wie gut wollen wir sein? | Was sichern wir Kunden zu? |
| Form | Messwert / Quote | Zielwert + Zeitraum | Vertragsklausel |
| Beispiel | 99,93 % erfolgreiche Prüfungen im Juni | ≥ 99,9 % in jedem 30-Tage-Fenster | ≥ 99,5 % im Kalendermonat, sonst 10 % Gutschrift |
| Adressat | Technik, Betrieb | Technik, Produktverantwortliche | Kunden, Vertrieb, Recht |
| Folge bei Verfehlung | keine, nur Information | Priorität verschiebt sich zugunsten Stabilität | Gutschrift, Vertragsstrafe, Kündigungsrecht |
| Wer legt es fest? | Team, per Messmethode | Team nach Geschäftsziel | Vertragspartner |
Häufig sieht man in Verträgen und Werbung nur Prozentzahlen („99,9 % Verfügbarkeit“) ohne die dahinterliegende Messung. Das ist ein SLO-Versprechen ohne SLI. Ohne Antwort auf „gemessen von wem, wie oft, womit, mit welchen Ausnahmen“ bleibt die Zahl Behauptung.
Wie definiert man ein sinnvolles SLI für eine Website?
Ein gutes SLI ist nah am Nutzererlebnis, eindeutig berechenbar und manipulationsarm. Die gängige Form ist ein Verhältnis aus „guten“ zu „gültigen“ Ereignissen:
SLI (%) = gute Ereignisse ÷ gültige Ereignisse × 100
Für Websites bieten sich folgende Varianten an:
| SLI-Art | Gutes Ereignis | Stärke | Schwäche |
|---|---|---|---|
| Erreichbarkeit | Prüfung liefert erlaubten Statuscode | einfach, leicht zu messen | erkennt Fehlerseiten mit 200 nicht |
| Erreichbarkeit + Inhalt | Statuscode ok und erwarteter Text vorhanden | näher an „funktioniert wirklich“ | Text muss gepflegt werden |
| Latenz | Antwort in unter 2.000 ms | erfasst „zu langsam“ als Teilausfall | Schwellenwert ist Ermessenssache |
| Zertifikat | Restlaufzeit über 14 Tage | verhindert vermeidbare Ausfälle | kein Qualitätsmaß im Alltag |
| Job-Pünktlichkeit | Heartbeat kam im erwarteten Fenster an | deckt Hintergrundprozesse ab | abhängig vom Sender |
Wählen Sie lieber ein bis drei aussagekräftige SLIs als zehn halbherzige. Für einen Onlineshop wären das etwa die Erreichbarkeit einer dynamischen Seite mit Inhaltsprüfung und die Latenz der Produktseite. Ein SLI sollte außerdem aus Sicht des Besuchers formuliert sein: Wenn die Startseite aus dem Cache kommt, die Warenkorbfunktion aber ausfällt, misst die Startseite das falsche Ereignis. Wie Messungen zustande kommen und welche Grenzen sie haben, lesen Sie in Grenzen automatischer Website-Prüfungen.
Legen Sie die Messmethode schriftlich fest. Mindestens diese Punkte gehören dazu:
- Prüfziel (genaue URL oder API-Endpunkt) und Erfolgskriterium (Statuscodes, Inhalt, Zeitlimit).
- Prüfintervall und Zahl der Fehlschläge, ab der ein Ereignis als Ausfall gilt.
- Zeitfenster der Auswertung (gleitende 30 Tage oder Kalendermonat).
- Umgang mit geplanter Wartung (zählt sie mit oder nicht?).
- Messort und Verhalten bei Messstörungen.
Was ist ein Fehlerbudget und wie rechnet man es aus?
Das Fehlerbudget ist die Differenz zwischen 100 % und dem SLO. Es drückt aus, wie viel Fehler oder Ausfall Sie sich im Zeitraum erlauben dürfen, ohne das Ziel zu verfehlen. Bei einem Zeitfenster von 30 Tagen (43.200 Minuten) gilt:
Fehlerbudget (Minuten) = (100 % − SLO) × 43.200 Minuten
| SLO | Budget je 30 Tage | Budget je Jahr (365 Tage) | Einordnung |
|---|---|---|---|
| 99 % | 432 Min. (7 h 12 Min.) | ca. 3,65 Tage | einfache Seiten, Vereine |
| 99,5 % | 216 Min. (3 h 36 Min.) | ca. 1,83 Tage | Firmenseiten ohne Umsatzbezug |
| 99,9 % | 43,2 Min. | ca. 8 h 46 Min. | Shops, Buchungssysteme |
| 99,95 % | 21,6 Min. | ca. 4 h 23 Min. | anspruchsvolle Shops, Portale |
| 99,99 % | 4,32 Min. | ca. 52,6 Min. | nur mit redundanter Architektur |
Bezogen auf einen durchschnittlichen Monat von etwa 30,4 Tagen (rund 43.800 Minuten) liegt das 99,9-%-Budget bei ungefähr 43,8 Minuten. Entscheidend ist, dass Sie den Zeitraum festlegen und dabei bleiben. Eine ausführlichere Einordnung, welche Werte für welche Seite sinnvoll sind, liefert Welche Uptime ist realistisch?.
Ein Shop setzt ein SLO von 99,9 % für 30 Tage; das Budget beträgt 43,2 Minuten. Im Zeitraum gab es drei Störungen: 12 Minuten (fehlerhaftes Plugin-Update), 9 Minuten (Datenbank-Neustart) und 20 Minuten (Hoster-Netzproblem). Summe: 41 Minuten, also 94,9 % des Budgets verbraucht, 2,2 Minuten bleiben. Die Praxisfolge: Für den Rest des Fensters werden riskante Änderungen (Updates, Migrationen) verschoben, bis neues Budget verfügbar ist, und die größte Einzelursache (Hoster) kommt auf die Prüfliste. Ohne SLO hätte man „ein paar Probleme im Monat“ festgestellt, mit SLO eine nachvollziehbare Entscheidung getroffen.
Das Budget ist ein Entscheidungswerkzeug: Ist es voll, hat Stabilität Vorrang vor neuen Funktionen. Ist es kaum genutzt, spricht nichts gegen schnellere Veröffentlichungen. So verlieren Diskussionen zwischen Entwicklung und Betrieb an Schärfe, weil es eine gemeinsame Zahl gibt.
Wie alarmiert man sinnvoll auf ein Fehlerbudget?
Ein Alarm bei jedem einzelnen Fehlschlag erzeugt Lärm; ein Alarm erst bei verbrauchtem Budget kommt zu spät. Das SRE-Workbook (siehe Quellen) beschreibt deshalb Alarme auf die Verbrauchsgeschwindigkeit („Burn Rate“): Eine Burn Rate von 1 bedeutet, das Budget wird exakt bis zum Fensterende aufgebraucht, 10 heißt, es ist zehnmal so schnell leer. Das Workbook nennt als Beispiel einen schnellen Alarm (hohe Burn Rate über kurze Zeit, etwa 14,4 über eine Stunde, entspricht 2 % des 30-Tage-Budgets) und einen langsamen Alarm (niedrigere Rate über Stunden bis Tage) für schleichende Probleme.
Für kleinere Betriebe ist die einfache Variante meist ausreichend:
- Sofort-Alarm bei bestätigter Störung (Seite nicht erreichbar).
- Warnung bei 50 % und 80 % Budgetverbrauch innerhalb des Fensters.
- Wochenrückblick: Welche Ursachen haben das Budget verbraucht?
Weitere Hinweise zu Kanälen und Eskalation finden Sie unter Benachrichtigungen richtig einrichten.
Worauf sollten Sie bei einem SLA achten?
Ein SLA ist nur so gut wie seine Kleinteile. Viele „99,9 %“-Zusagen sind bei genauem Lesen wesentlich enger gefasst, als sie klingen. Prüfen Sie vor dem Unterschreiben (oder beim Formulieren eigener SLAs):
| Klausel | Worauf achten? |
|---|---|
| Gegenstand | Gilt die Zusage für Ihre Website oder nur für Server/Netz des Anbieters? Hosting-SLAs beziehen sich oft auf die Infrastruktur, nicht auf Ihre Anwendung. |
| Messung | Wer misst, womit, wie oft? Ein Anbieter, der sich selbst misst, hat einen Interessenkonflikt. |
| Zeitraum | Kalendermonat, Quartal oder Jahr? Je länger der Zeitraum, desto mehr Ausfall lässt sich „ausmitteln“. |
| Ausnahmen | Wartungsfenster, höhere Gewalt, Angriffe, Kundenfehler: Wie viel Zeit ist ausgenommen? |
| Mindestdauer | Zählen Ausfälle unter einer Mindestdauer (z. B. 5 Minuten) nicht? |
| Rechtsfolgen | Gutschrift in Prozent der Monatsgebühr, Höchstgrenze, Sonderkündigungsrecht? |
| Meldepflicht | Muss der Kunde Ansprüche innerhalb einer Frist anmelden und belegen? |
| Reaktionszeiten | Wird nur Verfügbarkeit zugesagt oder auch Reaktions- und Wiederherstellungszeit des Supports? |
Angenommen, ein Hosting-Vertrag sagt 99,9 % Verfügbarkeit im Kalendermonat zu; bei weniger als 99,9 % gibt es 10 % der Monatsgebühr als Gutschrift, bei weniger als 99 % 25 %. Die Gebühr betrage 40 €, der Anbieter erreiche im Monat 99,5 % (216 Minuten Ausfall). Gutschrift: 10 % von 40 € = 4 €. Der Shop-Betreiber, der in dieser Zeit durchschnittlich 15 € Umsatz pro Minute verloren hat (Annahme), erlebt einen Schaden von mehreren tausend Euro. Die Gutschrift deckt es nicht annähernd. Das ist der Normalfall: SLA-Gutschriften sind keine Versicherung.
Rechtliche Details wie Haftungsbegrenzungen, Verträge mit Verbrauchern oder Vertragsstrafen sollten Sie von einer Fachperson prüfen lassen; dieser Ratgeber ersetzt keine Rechtsberatung.
Warum garantiert ein Hoster-SLA nicht die Verfügbarkeit Ihrer Website?
Eine Website besteht aus Abhängigkeiten in Reihe: Domain und DNS, Hosting, Anwendung, Datenbank, externe Dienste (Zahlungsanbieter, CDN, Mail), Zertifikat. Fällt ein Glied aus, ist die Seite für Besucher nicht nutzbar. Rechnerisch multiplizieren sich die Verfügbarkeiten der in Reihe geschalteten Komponenten:
Gesamtverfügbarkeit = V₁ × V₂ × V₃ × …
Drei Komponenten in Reihe: Hosting mit 99,9 %, DNS-Anbieter mit 99,9 % und Zahlungsanbieter mit 99,95 %. Gesamt: 0,999 × 0,999 × 0,9995 ≈ 0,9985, also 99,85 %. Das entspricht rund 65 Minuten Ausfall in 30 Tagen (0,15 % von 43.200 Minuten = 64,8 Minuten) – anderthalbmal so viel wie das Budget von 43,2 Minuten bei 99,9 %. Ohne eigene Fehler der Anwendung. Ein 99,9-%-Ziel für die Website setzt also bessere Zulieferer oder Redundanz voraus, sonst ist es rechnerisch unerreichbar.
Das gilt umgekehrt auch bei redundanten (parallelen) Komponenten, die sich gegenseitig ersetzen: Dann steigt die Gesamtverfügbarkeit, sofern die Umschaltung selbst zuverlässig funktioniert. Diese Rechnung ist ein Modell, das unabhängige Ausfälle voraussetzt; in der Realität treten Ausfälle häufig korreliert auf (gemeinsames Rechenzentrum, gemeinsamer Anbieter). Mehr zu typischen Ursachen steht in Ausfallursachen von Websites.
Welche typischen Fehler passieren im Umgang mit SLA, SLO und SLI?
- Ziel ohne Messung: „Wir haben 99,9 %“ ohne definierte Prüfungen. Gegenmaßnahme: SLI und Messmethode zuerst festlegen.
- Zu ehrgeiziges SLO: 99,99 % für eine Seite auf Shared Hosting. Gegenmaßnahme: Ziel aus Geschäftsschaden und Architektur ableiten, nicht aus Wunschdenken.
- SLO gleich SLA: Intern dasselbe Ziel wie vertraglich zugesagt. Gegenmaßnahme: intern strenger ansetzen, damit ein Puffer bleibt.
- Wartung nicht geregelt: Geplante Arbeiten verbrennen Budget oder werden stillschweigend ignoriert. Gegenmaßnahme: Regel schriftlich festhalten, siehe Wartungsfenster planen.
- Nur den Durchschnitt betrachten: Ein Monat mit 99,9 % kann aus einem einzigen 43-Minuten-Ausfall bestehen. Gegenmaßnahme: zusätzlich Anzahl und Dauer der Ereignisse auswerten.
- Zusagen an Kunden ohne eigene Datenbasis: Gegenmaßnahme: mindestens ein Quartal messen, bevor Sie ein SLA anbieten.
- Latenz ignorieren: Eine Seite, die in 15 Sekunden antwortet, gilt technisch als erreichbar. Gegenmaßnahme: ein Latenz-SLI ergänzen, vgl. Uptime und Antwortzeit.
Checkliste: SLO festlegen und einführen
- Kritische Nutzerwege benennen (Startseite, Produktseite, Checkout, Login, API).
- Pro Weg ein SLI definieren: Prüfziel, Erfolgskriterium, Zeitlimit.
- Prüfintervall und Bestätigungsanzahl festlegen und die Erkennungszeit notieren.
- Vier Wochen messen, ohne ein Ziel zu setzen: Wo stehen Sie wirklich?
- SLO knapp über dem Ist-Wert ansetzen und daraus das Fehlerbudget in Minuten berechnen.
- Regel für Wartung und externe Ursachen festlegen.
- Alarmschwellen für 50 % und 80 % Budgetverbrauch einrichten.
- Monatlich Bilanz ziehen: Welche Ursache hat wie viele Minuten gekostet?
- Erst danach über ein SLA mit Kunden nachdenken, mit Puffer zum SLO.
- Vertragsklauseln (Messung, Ausnahmen, Gutschriften) von Fachleuten prüfen lassen.
Grenzen und Einordnung
SLA/SLO/SLI sind ein Rahmen, kein Wundermittel. Sie machen nur sichtbar, was Sie messen; ein schlecht gewähltes SLI kann beruhigen, während Nutzer leiden. Ein SLO ersetzt keine Architekturentscheidung: Wer 99,99 % will, braucht Redundanz, Automatisierung und Notfallprozesse (siehe Ausfall-Notfallplan), keine Tabelle. Außerdem sind die Zahlen aus externen Stichproben immer Näherungen (Intervall, Standort, Prüfziel). Für belastbare Verträge lohnt es sich, die Messmethode im SLA selbst zu definieren und beiden Seiten Einsicht in die Rohdaten zu geben. Die Übertragung der Branchenkonzepte auf kleine Websites hat zudem Grenzen: Das SRE-Buch stammt aus dem Betrieb sehr großer Systeme, viele Verfahren (z. B. Burn-Rate-Alarme mit mehreren Zeitfenstern) lohnen sich erst ab einer gewissen Größe.
Wie setzen Sie SLO und Fehlerbudget mit UPTIMESHIELD um?
Im Dashboard können Sie je Monitor ein SLA-Ziel mit Fehlerbudget (30 Tage) hinterlegen und sehen, wie viel vom Budget verbraucht ist. Als SLI dient die gemessene Verfügbarkeit, die sich als Quote erfolgreicher Prüfungen ohne Wartungszeit berechnet; geplante Wartungsfenster zählen nicht mit. Die Berechnung beschreibt die Messmethodik. Für Kunden gibt es Berichte als PDF, CSV oder JSON sowie einen Monatsbericht (Pro und Max), öffentliche Statusseiten mit 30-Tage-Balken und Störungshistorie. Das Paket Max enthält zusätzlich einen SLA-Gutschriften-Rechner. Mit Inhaltsprüfung (Keyword, API/JSON) bilden Sie ein SLI ab, das über „Server antwortet“ hinausgeht, siehe Monitortypen. Die Funktionen nach Tarif zeigt die Seite Preise. UPTIMESHIELD liefert die Messung und Auswertung; die vertragliche Gestaltung eines SLA bleibt Ihre Aufgabe.
Quellen und weiterführende Standards
Externe Links führen zu den Original-Spezifikationen und offiziellen Dokumentationen. Die Einordnung und die Beispielrechnungen stammen aus der Messmethodik von UPTIMESHIELD.
Selbst prüfen: Testen Sie jetzt, ob Ihre Website erreichbar ist und wie schnell sie antwortet – mit dem Uptime Checker.