Ordlista · Mått på tillförlitlighet

Vad är burn rate?

Burn rate är hur snabbt en tjänst förbrukar sin felbudget, jämfört med vad dess SLO tillåter. Vid burn rate 1 räcker budgeten exakt hela fönstret; vid 2 är den slut halvvägs.

Så fungerar det och därför spelar det roll

Burn rate jämför felfrekvensen du ser nu med den frekvens som SLO:t tillåter. Med ett SLO på 99,9 % är den tillåtna felfrekvensen 0,1 %, så om 0,5 % av förfrågningarna misslyckas är burn rate 5, och i den takten räcker en felbudget på 30 dagar i 6 dagar.

Googles SRE workbook bygger larm på den. För en SLO på 99,9 % över 30 dagar föreslår den utlarmning när 2 % av budgeten förbrukas inom en timme (en burn rate på 14,4) eller 5 % inom sex timmar (en burn rate på 6), och att öppna ett ärende när 10 % förbrukas inom tre dagar (en burn rate på 1). Varje larm kontrollerar också ett kort fönster, så att det upphör strax efter att problemet gör det.

Ett totalt avbrott förbrukar budgeten snabbt, och ett enkelt larm om att ”webbplatsen är nere” fångar det lika snabbt: mot 99,9 % motsvarar varje minut nere en burn rate på 1 000. Larm på burn rate gör verklig nytta vid partiella fel, som att 2 % av förfrågningarna misslyckas i timmar, vilket aldrig tar ner webbplatsen men tömmer månadens budget.

Formel

Burn rate = observerad felfrekvens ÷ (100 % − SLO); tid tills budgeten är slut = fönster ÷ burn rate

Exempel: Mot ett SLO på 99,9 % har ett totalt avbrott en burn rate på 1 000, så 20 minuter av det förbrukar 46 % av en 30-dagarsbudget på 43 minuter och 12 sekunder. Om 0,5 % av kontrollerna misslyckas är burn rate 5, och budgeten är slut på 6 dagar.

Så hjälper Uptimecheck

Uptimecheck beräknar ingen burn rate. För tillgänglighet täcker larmen den snabba änden: med ett intervall på 1 minut når en driftstörning som bekräftats av en andra kontroll dig inom en eller två minuter. Larm om långsamhet, som skickas efter tre långsamma kontroller i rad, fångar en tjänst som är uppe men för långsam, och rapporter för de senaste 7, 30 eller 90 dagarna visar hur mycket av en budget som redan är förbrukad.

Se Upptidsövervakning

Kom igång Så får du larm vid långsamma svar Så tar du fram upptidsrapporter mot ett SLA-mål

Testa gratis Testa livedemon

14 dagar gratis · Sedan gratis för 5 övervakningar · Inget kreditkort

Läs mer i guiderna

Guides oktober 22, 2026 6 min läsning

Felbudget: vad det är och hur du använder den

Så räknar du ut en felbudget utifrån en SLO, vad som förbrukar den, hur burn rate fungerar och hur du skriver en felbudgetpolicy som teamet faktiskt följer.

Läs

Guides december 2, 2025 7 min läsning

Så minskar du falsklarm i upptidsövervakningen

Falsklarm lär teamet att ignorera övervakningen. Så skär du ner bruset: bekräfta varje fel med en andra kontroll, sätt rimliga timeouts, validera rätt URL och skicka larmen till dem som kan agera.

Läs

Frågor

Vilken tröskel är bra för burn rate-larm?

En vanlig start för ett SLO på 99,9 % över 30 dagar är att larma jouren vid en burn rate på 14,4 under en timme eller 6 under sex timmar, och att öppna ett ärende vid 1 under tre dagar. Justera efter några månader med riktiga larm.

Varför använder ett burn rate-larm två fönster?

Det långa fönstret säkerställer att tillräckligt mycket budget har förbrukats för att spela roll. Det korta fönstret säkerställer att den fortfarande förbrukas, så att larmet upphör strax efter att problemet är åtgärdat.

Är en burn rate på 1 dåligt?

Nej. Den förbrukar budgeten precis vid fönstrets slut, vilket är vad SLO:n tillåter. Över 1 tar budgeten slut i förtid; under 1 blir något kvar.

Mer från Mått på tillförlitlighet

Alla begrepp

Driftstopp är historia.

Sätt upp din första övervakning på under en minut, eller ta en titt i livedemon först.

Testa gratis Jämför planer