Een error budget is de hoeveelheid onbetrouwbaarheid die je SLO over een periode toestaat: 100% min het doel. Een SLO van 99,9% over 30 dagen laat een error budget van 43 minuten en 12 seconden downtime over, of één mislukt verzoek op elke duizend. Zolang er budget over is, kan het team releasen en risico’s nemen. Is het op, dan gaat betrouwbaarheidswerk voor tot het venster zich herstelt.
Die ene regel maakt van een betrouwbaarheidsdoel concrete beslissingen. Deze gids laat zien hoe je een error budget berekent, wat het wel en niet zou moeten verbruiken, hoe je ziet hoe snel je het verbruikt en hoe je een beleid schrijft voor als het op is.
Zo bereken je een error budget
Je hebt twee dingen nodig: een SLO, het betrouwbaarheidsdoel dat je jezelf stelt, en een venster, de periode waarover het wordt gemeten. Het error budget is wat er overblijft tussen het doel en perfectie.
Error budget = (100% − SLO) × window
Voor een SLO van 99,9% over 30 dagen (43.200 minuten): 0,1% × 43.200 = 43,2 minuten, oftewel 43 minuten en 12 seconden. De tabel toont dezelfde berekening voor gangbare doelen, naar beneden afgerond op de seconde.
SLOBudget per 30 dagenBudget per 90 dagen99%7u 12m21u 36m99,5%3u 36m10u 48m99,9m 12s2u 9m 36s99,95m 36s1u 4m 48s99,99%4m 19s12m 57s
De SLA- en uptimecalculator doet dit voor elk doel en elke periode. Die rekent met de gemiddelde maand (een jaar gedeeld door 12) en toont daarom 43 minuten en 49 seconden voor 99,9%, in plaats van het 30-dagencijfer hierboven.
Op basis van tijd of van verzoeken
Een error budget kun je in twee eenheden tellen, afhankelijk van de SLI achter je SLO:
Op basis van tijd: minuten downtime, gemeten met checks van buitenaf. Eenvoudig, makkelijk uit te leggen en het past bij hoe de meeste SLA’s met klanten zijn opgesteld. Een maandelijkse SLO van 99,9% staat ongeveer 43 minuten toe.
Op basis van verzoeken: het aandeel mislukte verzoeken, geteld uit de logs van de load balancer of de applicatie. Bij 2 miljoen verzoeken per maand en 99,9% is het budget 2.000 mislukte verzoeken. Drukke uren wegen zwaarder dan rustige, wat dichter bij de ervaring van gebruikers ligt, maar je hebt logging nodig waarop je kunt vertrouwen.
Veel teams gebruiken beide: een tijdgebaseerd budget op basis van externe checks voor de dienst als geheel, en verzoekgebaseerde budgetten voor de endpoints die het meest tellen, zoals de checkout of de API.
Waarom überhaupt een error budget
Zonder budget is betrouwbaarheid een discussie. Product wil releasen, engineering wil afremmen, en wie het laatst praat, wint. Een budget vervangt die discussie door een getal waar beide kanten vooraf mee hebben ingestemd.
Het maakt 100% het verkeerde doel. Een doel van 100% laat geen budget over, dus elke deploy is een risico dat niemand mag nemen. Gebruikers merken via hun eigen wifi en mobiele netwerk toch geen verschil tussen 99,99% en 100%.
Het maakt risico besteedbaar. Een grote migratie, een nieuwe regio of een riskante release kun je zo plannen dat die past in het budget dat er deze maand nog over is.
Het bepaalt de prioriteiten voor je. Is het budget op, dan zegt het beleid wat er daarna gebeurt, zodat niemand een vergadering hoeft te winnen om betrouwbaarheidswerk op de roadmap te krijgen.
Wat het budget verbruikt
Alles wat je SLI als slecht telt, verbruikt budget. Bepaal dat wanneer je de SLO opstelt, niet tijdens het incident.
Bevestigde storingen: de dienst antwoordde niet, antwoordde met een fout of met de verkeerde inhoud.
Trage responses, als je SLI zegt dat een verzoek boven een bepaalde grens als mislukt telt. Een pagina die 30 seconden nodig heeft, is up, maar niet bruikbaar.
Mislukte deploys en rollbacks, voor de minuten dat gebruikers fouten zagen.
Storingen bij je leveranciers. Valt je betaalprovider of DNS-host uit, dan kunnen je gebruikers nog steeds niet afrekenen. Het verbruikt je budget, ook al ligt de oplossing niet bij jou, en dat is een goede reden om de diensten waarvan je afhankelijk bent te bewaken.
Gepland onderhoud, alleen als de SLO dat zegt. Veel teams sluiten aangekondigde onderhoudsvensters uit, met een maximum per maand.
Wat het niet zou moeten verbruiken: false positives. Eén mislukte check door een netwerkhapering is geen downtime. Bevestig een fout met een tweede check voordat je die meetelt, anders loopt je budget leeg aan problemen die gebruikers nooit hebben gezien.
Burn rate: hoe snel je verbruikt
Het budget vertelt hoeveel falen je je kunt veroorloven. De burn rate vertelt hoe snel je het opmaakt. Het SRE-workbook van Google definieert die als hoe snel de dienst, ten opzichte van de SLO, het error budget verbruikt (Alerting on SLOs).
Bij een burn rate van 1 is het hele budget precies aan het eind van het venster op.
Bij een burn rate van 2 is het in de helft van het venster op: na 15 dagen van een maand van 30 dagen.
Een volledige storing brandt met 1.000 tegen een SLO van 99,9%, omdat elke minuut down duizend keer het toegestane tempo is. Twintig minuten daarvan verbruiken 46% van een budget van 30 dagen.
Het aanbevolen startpunt uit het workbook voor een SLO van 99,9% piept iemand op als 2% van een budget van 30 dagen binnen een uur opbrandt (een burn rate van 14,4) of 5% binnen zes uur (een burn rate van 6), en maakt een ticket aan als 10% binnen drie dagen opbrandt (een burn rate van 1). Elke alert controleert ook een kort venster, zodat hij kort nadat het probleem stopt ook stopt.
Bij een harde storing gaan een burn rate-alert en een gewone alert “site is down” ongeveer tegelijk af. Burn rates bewijzen hun waarde bij gedeeltelijke storingen: 3% van de verzoeken die urenlang mislukt, wat de site nooit platlegt maar het budget van de maand ongemerkt al op woensdag opmaakt.
Schrijf een error budget-beleid
Een budget zonder beleid is gewoon een getal op een dashboard. Het beleid legt vooraf vast wat het team doet bij elk niveau van verbruik. Spreek het af met product en engineering samen, en leg het vast op een plek waar beide het kunnen vinden. Google publiceert een voorbeeld van een error budget-beleid dat de moeite waard is om te lezen voordat je je eigen beleid schrijft.
Een eenvoudig beleid om mee te beginnen
Budget over: release zoals normaal. Gepland riskant werk gaat door.
De helft op voor het midden van het venster: de on-call lead bekijkt de incidenten tot nu toe en benoemt de grootste oorzaak.
Budget op: alleen bugfixes en betrouwbaarheidswerk gaan live tot het venster zich herstelt. Riskante migraties wachten.
Eén incident verbruikte meer dan een vijfde van het budget: daar komt een schriftelijke postmortem van met minstens één actiepunt.
Uitzonderingen worden genomen door benoemde mensen, zoals het hoofd engineering en het hoofd product samen, en vastgelegd.
De drempels zijn voorbeelden, geen regels. Kies drempels waar je team zich echt aan houdt. Een beleid dat de eerste keer dat het knelt wordt genegeerd, is erger dan geen beleid, omdat iedereen dan leert dat de SLO er niet toe doet.
Veelgemaakte fouten
De SLO gelijkstellen aan de SLA. Dan is het budget op precies op het moment dat je klanten service credits verschuldigd bent. Houd de SLO strenger dan de SLA, zodat het interne alarm eerst afgaat. SLA vs SLO vs SLI legt uit hoe de drie samenhangen.
Een te kort venster. Een weekbudget wordt gereset voordat een slechte week iets kan veranderen. Dertig dagen, doorlopend of per kalendermaand, is de gebruikelijke keuze.
Vergeten hoe het venster wordt gereset. Een kalendermaand begint op de 1e opnieuw, dus een slechte laatste week is binnen een paar dagen vergeten. Een doorlopend venster van 30 dagen onthoudt die een maand lang, wat strenger en eerlijker is.
Alleen naar het totaal kijken. Eén storing van 40 minuten en veertig storingen van 1 minuut verbruiken hetzelfde budget, maar de tweede verstoort elke dag het werk van gebruikers. Houd naast het budget ook het aantal incidenten en de MTTR bij.
Alleen van binnenuit meten. Serverlogs kunnen geen verzoeken vastleggen die nooit zijn aangekomen. Een verlopen certificaat of een kapot DNS-record verbruikt budget dat alleen een externe check ziet.
Een tijdgebaseerd error budget bijhouden met Uptimecheck
Uptimecheck geeft je de cijfers die een tijdgebaseerd budget nodig heeft. Uptime monitoring controleert zo vaak als elke minuut vanuit Stockholm, Londen en New York, en bevestigt elke mislukte check vanaf een tweede locatie, zodat één hapering geen budget kost. Onderhoudsvensters en gepauzeerde tijd tellen niet mee voor de uptime.
Rapporten tonen uptime, downtime en incidenten per monitor voor deze maand, vorige maand of de laatste 7, 30 of 90 dagen, tegen een SLA-doel van 99%, 99,5%, 99,9%, 99,95% of 99,99%, met een CSV-download. Het resterende budget is de toegestane downtime min de downtime in het rapport. Zie hoe je rapporten draait tegen een SLA-doel.
Incidenten bewaren het bewijs en een tijdlijn van elke check, alert en notitie, precies wat een postmortem nodig heeft. Zie incidentbeheer.
Onderhoudsvensters houden gepland werk buiten de cijfers. Zie hoe je onderhoudsvensters plant.
Wil je een prijskaartje hangen aan het budget dat je verbruikt, probeer dan de calculator voor de kosten van downtime. Lees wat 99,9% uptime betekent om te zien wat elk doel toestaat.
Weet hoeveel budget je nog hebt voordat de maand voorbij is. Probeer Uptimecheck 14 dagen gratis, geen creditcard nodig.