Glossar · Zuverlässigkeitskennzahlen
Die Burn Rate gibt an, wie schnell ein Dienst sein Fehlerbudget verbraucht, gemessen an dem, was sein SLO erlaubt. Bei einer Burn Rate von 1 reicht das Budget genau für das ganze Zeitfenster, bei 2 ist es nach der Hälfte aufgebraucht.
Die Burn Rate vergleicht die aktuelle Fehlerrate mit der Rate, die das SLO erlaubt. Bei einem SLO von 99,9 % liegt die erlaubte Fehlerrate bei 0,1 %, sodass 0,5 % fehlgeschlagene Anfragen eine Burn Rate von 5 bedeuten – in diesem Tempo reicht ein Fehlerbudget für 30 Tage nur 6 Tage.
Googles SRE Workbook stützt Alarme darauf. Für ein SLO von 99,9 % über 30 Tage empfiehlt es, zu pagen, wenn 2 % des Budgets innerhalb einer Stunde verbrennen (eine Burn Rate von 14,4) oder 5 % innerhalb von sechs Stunden (eine Burn Rate von 6), und ein Ticket zu eröffnen, wenn 10 % innerhalb von drei Tagen verbrennen (eine Burn Rate von 1). Jeder Alarm prüft zusätzlich ein kurzes Fenster, damit er bald nach dem Problem auch wieder endet.
Ein Totalausfall verbraucht das Budget schnell, und ein einfacher „Website ist down“-Alarm erkennt ihn genauso schnell: Bei 99,9 % entspricht jede Minute Ausfall einer Burn Rate von 1.000. Burn-Rate-Alarme lohnen sich bei Teilausfällen, etwa wenn über Stunden 2 % der Anfragen fehlschlagen. Das legt die Website nie lahm, leert aber das Budget des Monats.
Burn Rate = beobachtete Fehlerrate ÷ (100 % − SLO); Zeit, bis das Budget aufgebraucht ist = Zeitfenster ÷ Burn Rate
Beispiel: Bei einem SLO von 99,9 % liegt die Burn Rate bei einem Totalausfall bei 1.000, sodass 20 Minuten davon 46 % eines 30-Tage-Budgets von 43 Minuten und 12 Sekunden verbrauchen. 0,5 % fehlgeschlagene Prüfungen ergeben eine Burn Rate von 5 und leeren das Budget in 6 Tagen.
Uptimecheck berechnet keine Burn Rate. Bei der Verfügbarkeit decken die Alarme das schnelle Ende ab: Bei einem 1-Minuten-Intervall erreicht Sie ein von einem zweiten Check bestätigter Ausfall innerhalb von ein, zwei Minuten. Langsam-Alarme, gesendet nach drei langsamen Checks in Folge, erkennen einen Dienst, der erreichbar, aber zu langsam ist, und Berichte für die letzten 7, 30 oder 90 Tage zeigen, wie viel eines Budgets schon verbraucht ist.
14 Tage kostenlos testen · Danach gratis für 5 Monitore · Keine Kreditkarte
Guides 6 Min. Lesezeit
Wie Sie ein Error Budget aus einem SLO berechnen, was es verbraucht, wie die Burn Rate funktioniert und wie Sie eine Error-Budget-Policy schreiben, an die sich Ihr Team wirklich hält.
LesenGuides 7 Min. Lesezeit
Fehlalarme bringen Teams bei, das Monitoring zu ignorieren. So reduzieren Sie das Rauschen: jeden Fehler mit einem zweiten Check bestätigen, sinnvolle Timeouts setzen, die richtige URL prüfen und Alarme an die Leute leiten, die handeln können.
LesenEin üblicher Start für ein SLO von 99,9 % über 30 Tage ist, bei einer Burn Rate von 14,4 über eine Stunde oder 6 über sechs Stunden zu alarmieren und bei 1 über drei Tage ein Ticket zu eröffnen. Passen Sie das nach einigen Monaten echter Alarme an.
Das lange Fenster stellt sicher, dass genug Budget verbraucht wurde, um relevant zu sein. Das kurze Fenster stellt sicher, dass es noch immer verbraucht wird, sodass der Alarm kurz nach der Behebung endet.
Nein. Dann ist das Budget genau am Ende des Zeitfensters aufgebraucht, und genau das erlaubt das SLO. Über 1 ist das Budget früher erschöpft; unter 1 bleibt etwas übrig.
Richten Sie Ihren ersten Monitor in weniger als einer Minute ein – oder sehen Sie sich zuerst die Live-Demo an.
14 Tage kostenlos testen · Danach gratis für 5 Monitore · Keine Kreditkarte
Mit Ihrer Zustimmung zeigen uns Google Analytics und Microsoft Clarity, welche Seiten helfen und wo Besucher nicht weiterkommen. Sie setzen Cookies für bis zu 13 Monate. Ohne Ihre Zustimmung läuft keines der beiden. Sie können Ihre Entscheidung jederzeit unter Cookie-Einstellungen unten auf der Seite ändern. Datenschutzerklärung