Słownik · Wskaźniki niezawodności

Czym jest burn rate?

Burn rate to tempo, w jakim usługa zużywa budżet błędów, w porównaniu z tym, na co pozwala jej SLO. Przy burn rate 1 budżet wystarcza dokładnie na całe okno; przy 2 kończy się w połowie.

Jak to działa i dlaczego to ważne

Burn rate porównuje bieżący odsetek błędów z odsetkiem, na jaki pozwala SLO. Przy SLO 99,9% dopuszczalny odsetek błędów to 0,1%, więc 0,5% nieudanych żądań oznacza burn rate 5, a w tym tempie 30-dniowy budżet błędów wystarczy na 6 dni.

Na nim opiera alerty SRE workbook Google. Dla SLO 99,9% w ciągu 30 dni zaleca wzywanie dyżurnego, gdy 2% budżetu zostanie zużyte w ciągu godziny (burn rate 14,4) lub 5% w ciągu sześciu godzin (burn rate 6), a otwarcie zgłoszenia, gdy 10% zostanie zużyte w ciągu trzech dni (burn rate 1). Każdy alert sprawdza też krótkie okno, więc wygasa wkrótce po ustąpieniu problemu.

Pełna awaria szybko spala budżet, a zwykły alert „strona nie działa” wyłapuje ją równie szybko: przy 99,9% każda minuta przestoju to burn rate 1000. Alerty oparte na burn rate sprawdzają się przy częściowych awariach, np. gdy przez wiele godzin zawodzi 2% żądań – strona nigdy nie przestaje działać, ale budżet na cały miesiąc znika.

Wzór

Burn rate = obserwowany odsetek błędów ÷ (100% − SLO); czas do wyczerpania budżetu = okno ÷ burn rate

Przykład: Przy SLO 99,9% pełna awaria spala budżet w tempie 1000, więc 20 minut takiej awarii zużywa 46% 30-dniowego budżetu wynoszącego 43 minuty i 12 sekund. 0,5% nieudanych sprawdzeń to burn rate 5, który wyczerpuje budżet w 6 dni.

Jak pomaga Uptimecheck

Uptimecheck nie oblicza burn rate. W przypadku dostępności jego alerty obejmują szybki koniec skali: przy interwale 1-minutowym awaria potwierdzona drugim sprawdzeniem dociera do Ciebie w ciągu minuty lub dwóch. Alerty o spowolnieniu, wysyłane po trzech wolnych sprawdzeniach z rzędu, wychwytują usługę, która działa, ale za wolno, a raporty za ostatnie 7, 30 lub 90 dni pokazują, jaka część budżetu została już wykorzystana.

Zobacz: Monitorowanie dostępności

Konfiguracja Jak otrzymywać alerty o wolnych odpowiedziach Jak tworzyć raporty dostępności względem celu SLA

Wypróbuj za darmo Wypróbuj demo na żywo

14 dni za darmo · Potem 5 monitorów gratis · Bez karty kredytowej

Więcej w poradnikach

Guides 22 października, 2026 6 min czytania

Budżet błędów: czym jest i jak z niego korzystać

Jak obliczyć budżet błędów na podstawie SLO, co go zużywa, jak działa burn rate i jak napisać politykę budżetu błędów, której Twój zespół naprawdę będzie przestrzegać.

Czytaj

Guides 2 grudnia, 2025 7 min czytania

Jak ograniczyć fałszywe alerty w monitorowaniu dostępności

Fałszywe alerty uczą zespoły ignorować monitoring. Jak ograniczyć szum: potwierdzaj każdą awarię drugim testem, ustaw rozsądne limity czasu, sprawdzaj właściwy adres URL i kieruj alerty do osób, które mogą zareagować.

Czytaj

Pytania

Jaki próg alertu burn rate jest dobry?

Częsty punkt wyjścia dla SLO 99,9% w ciągu 30 dni to powiadamianie dyżurnego przy burn rate 14,4 w ciągu godziny lub 6 w ciągu sześciu godzin oraz otwieranie zgłoszenia przy 1 w ciągu trzech dni. Dostosuj progi po kilku miesiącach prawdziwych alertów.

Dlaczego alert burn rate używa dwóch okien?

Długie okno daje pewność, że spalono wystarczająco dużo budżetu, by miało to znaczenie. Krótkie okno daje pewność, że nadal się spala, więc alert wygasa wkrótce po usunięciu problemu.

Czy burn rate równy 1 to źle?

Nie. Zużywa budżet dokładnie do końca okna, na co pozwala SLO. Powyżej 1 budżet kończy się wcześniej; poniżej 1 część zostaje.

Więcej z działu: Wskaźniki niezawodności

Wszystkie pojęcia

Przestoje to przeszłość.

Skonfiguruj pierwszy monitor w niecałą minutę albo najpierw rozejrzyj się w demo na żywo.

Wypróbuj za darmo Porównaj plany