Error-Budget und Burn-Rate: SLO-Monitoring aufsetzen

SLI, SLO und SLA sauber trennen

Die drei Begriffe werden oft synonym benutzt - und genau das führt zu falschen Erwartungen. Sie bezeichnen drei verschiedene Dinge, die aufeinander aufbauen. Ein SLI (Service Level Indicator) ist die tatsächlich gemessene Größe: die reale Verfügbarkeit, etwa 99,94 % im letzten Monat. Ein SLO (Service Level Objective) ist das intern gesetzte Ziel für diese Größe, zum Beispiel 99,9 % über 30 Tage. Eine SLA (Service Level Agreement) ist die vertragliche Zusage gegenüber dem Kunden, rechtlich bindend und mit Konsequenzen bei Nichteinhaltung (Atlassian).

Die Reihenfolge ist entscheidend: Der SLI liefert die Messung, das SLO setzt darauf das interne Ziel, und die SLA ist das externe Versprechen, das auf diesem Ziel fußt (SigNoz). In der Praxis sollte das SLO deshalb stets strenger sein als die SLA - der Puffer dazwischen ist Ihr Sicherheitsabstand. Wer dem Kunden 99,5 % zusagt, sollte intern auf 99,9 % zielen, damit eine kleine Störung nicht sofort eine Vertragsverletzung auslöst. Ein SLO von 99,99 % bedeutet konkret, dass der Ausfall über einen Monat unter 4,32 Minuten bleiben muss (Atlassian) - eine Marke, die ohne kontinuierliche Messung kaum einzuhalten ist.

In der Praxis scheitern viele Teams nicht an der Technik, sondern an der Verwechslung dieser Ebenen. Wer den SLI für das Ziel hält, optimiert die Messung statt das Ergebnis. Wer das SLO mit der SLA gleichsetzt, gibt den Sicherheitspuffer auf und liefert dem Kunden faktisch keine Reserve. Sinnvoll ist es, mit wenigen, klar definierten SLOs zu beginnen - idealerweise für die wichtigsten Nutzerpfade - und sie erst dann auszuweiten, wenn die Messung verlässlich läuft (Nobl9). Ein einziges, sauber gemessenes Verfügbarkeits-SLO für die Startseite ist wertvoller als ein Dutzend halbgarer Kennzahlen, die niemand pflegt.

Wichtig ist die Erkenntnis, dass ein SLO sich an der Nutzererfahrung orientieren sollte, nicht an reiner Infrastruktur. Eine Antwortzeit-Messung von 200 Millisekunden ist wertlos, wenn der Checkout trotzdem die Hälfte der Bestellungen verliert. Nobl9 formuliert es so: solche Messungen sagen aus, ob die Infrastruktur läuft, aber nicht, ob der Nutzer seine Aufgabe erledigen kann (Nobl9). Ein gutes SLO bildet deshalb eine echte Nutzerinteraktion ab - die Erreichbarkeit der Startseite, die Funktion des Logins, die Ladezeit der Produktseite.

Was 99,9 Prozent wirklich bedeuten

Das Error-Budget ist schlicht die Umkehrung des SLO: Error-Budget = 100 % minus SLO (Google SRE Book). Bei 99,9 % bleiben also 0,1 % der Zeit für Ausfälle - und 0,1 % eines Monats sind eben jene 43,8 Minuten. Jede zusätzliche Neun verschärft das dramatisch: Der Sprung von 99,9 % auf 99,99 % senkt das monatliche Budget von rund 43 Minuten auf gut 4 Minuten (Google SRE Book - Availability Table). Nobl9 weist ausdrücklich darauf hin, dass jede weitere Neun exponentiell mehr kostet und dem Nutzer meist nur abnehmenden Mehrwert bringt (Nobl9). Realistische Ziele schlagen perfekte Ziele.

Diese Tabelle ist der Realitätscheck für jedes Verfügbarkeitsversprechen. Wer Kunden 99,99 % zusagt, gibt sich praktisch kein Wartungsfenster mehr - ein einziger schlecht geplanter Deploy kann das Monatsbudget aufbrauchen. Die Differenz zwischen Hosting-Werbung und tatsächlichem Spielraum erläutert auch der Beitrag zum Vergleich von Uptime-Garantien der Hoster, und wie sich eine SLA korrekt berechnen lässt, vertieft der Artikel zur Uptime-SLA-Berechnung.

Burn-Rate: wie schnell das Budget brennt

Die Burn-Rate beschreibt, wie schnell das Error-Budget verbraucht wird. Eine Burn-Rate von 1 bedeutet, dass das Budget genau im erwarteten Tempo aufgebraucht wird - es reicht exakt bis zum Monatsende. Eine Burn-Rate von 2 verbraucht doppelt so schnell: Das Budget ist nach 15 statt 30 Tagen erschöpft. Genau dieser Wert ist die entscheidende Frühwarnung. Wer nur am Monatsende die Verfügbarkeit prüft, bemerkt eine schleichende Verschlechterung erst, wenn die SLA bereits gerissen ist.

Der Vorteil der Burn-Rate gegenüber einer reinen Uptime-Zahl liegt im Tempo der Erkennung. Eine momentane Störung mit hoher Burn-Rate frisst in kurzer Zeit große Teile des Budgets. Statt zu warten, bis ein willkürlicher Schwellenwert wie 99 % erreicht ist, alarmiert die Burn-Rate, sobald das Verbrauchstempo gefährlich wird. Damit verschiebt sich die Frage von Ist die Seite gerade unten? hin zu Verbrennen wir gerade unser Budget zu schnell? - und genau das ist die handlungsleitende Frage.

Ein anschauliches Rechenbeispiel macht den Unterschied greifbar. Bei einem SLO von 99,9 % beträgt das Monatsbudget 43,8 Minuten. Fällt ein Dienst eine Stunde lang vollständig aus, ist das gesamte Budget eines Monats in einem einzigen Vorfall überschritten - die Burn-Rate in diesem Fenster liegt weit über dem Faktor 1. Tritt derselbe einstündige Ausfall dagegen verteilt als sechs kurze Störungen über das Quartal auf, bleibt die durchschnittliche Burn-Rate moderat, und das Budget reicht möglicherweise aus. Dieselbe Ausfallsumme kann also je nach Verteilung unkritisch oder fatal sein - und nur die Burn-Rate-Betrachtung unterscheidet beide Fälle zuverlässig.

Multi-Window-Burn-Rate-Alerts gegen Alarm-Müdigkeit

Hier liegt das eigentliche Handwerk. Ein einzelner Schwellenwert erzeugt entweder zu viele Fehlalarme oder reagiert zu langsam. Alarmiert man zu empfindlich, wird das Team mit Rauschen überschüttet; alarmiert man zu träge, bleibt eine echte Störung lange unbemerkt. Die Folge ist Alarm-Müdigkeit - und die ist messbar gefährlich: In der SANS Detection and Response Survey 2025 zeigte sich, dass ein Großteil der Alerts ungeprüft liegen bleibt - rund 67 % werden letztlich ignoriert - und mehr als 60 % der Teams häufig oder sehr häufig mit Fehlalarmen kämpfen (SANS 2025). Wenn jeder Alarm dringend wirkt, ist am Ende keiner mehr dringend.

Die Lösung ist das Multi-Window-Multi-Burn-Rate-Alerting, wie es das Google SRE Workbook beschreibt. Statt eines einzelnen Fensters werden mehrere kombiniert: ein kurzes Fenster prüft, ob das Problem gerade jetzt noch aktiv ist, ein langes Fenster bestätigt, dass der Budget-Verbrauch nachhaltig ist. Erst wenn beide Bedingungen gleichzeitig zutreffen, feuert der Alarm. Als Faustregel gilt: das Kurzfenster sollte rund ein Zwölftel der Dauer des Langfensters betragen (Google SRE Workbook). So feuert der Alarm schnell - und verstummt auch wieder zügig, sobald die Störung behoben ist.

Diese Werte aus dem Google SRE Workbook gelten für ein 99,9-Prozent-SLO und sind ein bewährter Startpunkt, kein Dogma (Google SRE Workbook). Die Logik dahinter: Eine sehr hohe Burn-Rate über ein kurzes Fenster (14,4x in einer Stunde frisst 2 % des Monatsbudgets) verlangt sofortiges Eingreifen und löst eine Eskalation aus. Eine niedrige Burn-Rate über drei Tage (1x, 10 % Budget) ist kein Notfall, sondern ein Hinweis - ein Ticket reicht. So bekommt das Team nur dann eine dringende Benachrichtigung, wenn es wirklich brennt. Wie man Alarme grundsätzlich so konfiguriert, dass sie handlungsleitend bleiben, vertieft der Beitrag zur richtigen Konfiguration von Monitoring-Alerts.

Error-Budget-Policy: aus Zahlen werden Entscheidungen

Ein Error-Budget entfaltet seinen Wert erst, wenn an seinen Verbrauch konkrete Handlungen geknüpft sind. Nobl9 bringt es auf den Punkt: Error-Budgets funktionieren nur, wenn Teams sie ernst nehmen (Nobl9). Eine typische Policy koppelt das Budget an die Release-Geschwindigkeit: Solange genug Budget vorhanden ist, darf das Team frei deployen. Ist das Budget eines kritischen Dienstes aufgebraucht, werden neue Feature-Releases eingefroren, bis sich die Lage stabilisiert hat - die Energie fließt dann in Stabilität statt in neue Funktionen.

1. Budget definieren - SLO festlegen (etwa 99,9 %) und das daraus folgende Monatsbudget berechnen (43,8 Minuten)
2. Burn-Rate messen - kontinuierlich erfassen, wie schnell das Budget verbraucht wird, statt nur die Endsumme zu prüfen
3. Multi-Window-Alerts schalten - schnelle Pages bei hoher Burn-Rate, ruhige Tickets bei langsamer Erosion
4. Policy anwenden - bei erschöpftem Budget Releases pausieren und Stabilisierung priorisieren
5. Budget zurücksetzen - mit jedem neuen Messzeitraum beginnt ein frisches Budget, und der Zyklus startet erneut

Diese Kopplung macht aus einer Kennzahl ein echtes Steuerungsinstrument zwischen Engineering und Produktmanagement. Sie beendet die unproduktive Debatte zwischen Wir müssen schneller liefern und Wir müssen stabiler werden, weil das Budget objektiv entscheidet, welcher Modus gerade angebracht ist. Wenn ein Vorfall doch eskaliert, hilft ein klar definierter Ablauf, die Reaktionszeit kurz zu halten - dazu liefert der Beitrag zu Incident-Management und Eskalation den passenden Rahmen.

Verfügbarkeit von mehreren Standorten messen

Ein SLO ist nur so gut wie die Messung dahinter. Wird die Verfügbarkeit von einem einzigen Ort aus geprüft, verzerrt jede lokale Netz- oder Routing-Störung den SLI - mal meldet das Monitoring einen Ausfall, den kein Nutzer erlebt, mal übersieht es einen regionalen Ausfall komplett. Eine Messung von mehreren geografisch verteilten Standorten glättet diese Verzerrung und liefert einen belastbaren Ist-Wert. Warum ein einzelner Prüfpunkt nicht ausreicht, erläutert der Beitrag zum Multi-Location-Monitoring.

XICTRAQ prüft die Verfügbarkeit deshalb von drei verteilten Standorten aus und bestätigt einen Ausfall erst, wenn mehrere Prüfpunkte ihn unabhängig melden. Das reduziert Fehlalarme aus einzelnen Netzwegen und sorgt für einen SLI, dem das Team vertraut. Die lückenlose Uptime-Historie liefert zugleich die Datenbasis, aus der sich Error-Budget und Burn-Rate überhaupt erst berechnen lassen - ohne historische Messreihe gibt es kein Budget-Tracking.

Geplante Wartung verdient besondere Aufmerksamkeit: Sie soll das Error-Budget nicht belasten, wenn sie korrekt angekündigt und ausgeklammert wird. Werden Wartungsfenster nicht sauber ausgenommen, erzeugen sie Fehlalarme und verfälschen den SLI. Wie sich solche geplanten Zeiten vom echten Ausfall trennen lassen, beschreibt der Beitrag zu Wartungsfenstern und falschen Alarmen.

SLO-Monitoring im Kontext von Compliance und Risiko

Verfügbarkeit ist nicht nur eine technische, sondern zunehmend auch eine regulatorische Größe. Für Betreiber wichtiger Dienste verlangt die NIS2-Richtlinie ein angemessenes Verfügbarkeits- und Vorfallmanagement samt Meldepflichten - ein dokumentiertes SLO-Monitoring liefert dafür einen belastbaren Nachweis. Welche Pflichten konkret auf Website-Betreiber zukommen, ordnet der Beitrag zu den NIS2-Meldepflichten für Website-Betreiber ein.

Auch die Ursachen von Verfügbarkeitsverlusten gehören in den Blick. Ein großer Teil ungeplanter Ausfälle entsteht nicht durch Software-Bugs, sondern durch Angriffe oder Infrastrukturstörungen - etwa Überlastungsangriffe, die einen Dienst gezielt unerreichbar machen. Wie sich solche Lastspitzen abfedern lassen, beschreibt der Beitrag zum Schutz vor DDoS- und DNS-Amplification-Angriffen. Ein SLO-Monitoring macht den daraus folgenden Budget-Verbrauch sichtbar und verbindet so die Sicht der Sicherheit mit der Sicht der Verfügbarkeit.

Der wirtschaftliche Hebel ist beträchtlich. In Unternehmensumgebungen wird der Schaden pro Ausfallminute auf rund 5.600 US-Dollar geschätzt (Gartner) - eine Zahl, die je nach Geschäftsmodell stark schwankt, aber die Größenordnung verdeutlicht. Jede vermiedene Burn-Rate-Spitze, die frühzeitig erkannt und gestoppt wird, schlägt sich damit unmittelbar im Ergebnis nieder. Wer den eigenen Wert kennen will, findet im Beitrag zu den Kosten von Website-Ausfällen eine passende Rechengrundlage.

Häufig gestellte Fragen zu Error-Budget und Burn-Rate