Een SLI (service level indicator) is een meting van hoe je dienst zich gedraagt, zoals het aandeel geslaagde requests. Een SLO (service level objective) is het interne doel voor die meting, zoals 99,9% geslaagde checks over 30 dagen. Een SLA (service level agreement) is de belofte die je aan klanten doet, meestal met een lager doel dan de SLO en een gevolg als je het niet haalt, zoals een service credit. De indicator is wat je meet, het doel is waar je naar streeft, en de overeenkomst is wat je tekent.
Deze gids legt elk begrip uit met voorbeelden, laat zien wat uptimepercentages in minuten betekenen, en helpt je indicatoren te kiezen voor een website of API, te bepalen wat als downtime telt en een SLA te schrijven die klanten begrijpen.
De drie begrippen in gewone taal
SLI: de meting
Een service level indicator is een getal dat je uit echte data kunt berekenen. Het is bijna altijd een verhouding: goede gebeurtenissen gedeeld door alle gebeurtenissen. Voor een website kan dat het aandeel uptimechecks zijn dat de verwachte respons gaf. Voor een API kan het het aandeel requests zijn dat binnen 500 milliseconden antwoordde met een status die geen 5xx is. Aan een SLI hangt geen doel. Die zegt alleen wat er gebeurd is.
SLO: het doel
Een service level objective koppelt een doel en een tijdvenster aan een SLI. “99,9% van de checks op de checkout slaagt, gemeten over voortschrijdende 30 dagen” is een SLO. Het is een intern instrument. Het vertelt het team wanneer de betrouwbaarheid goed genoeg is om features te blijven uitbrengen, en wanneer het tijd is om gas terug te nemen en dingen te repareren.
SLA: het contract
Een service level agreement is de externe belofte, vastgelegd in een contract of in de servicevoorwaarden. Daarin staan de dienst, het doel, hoe er gemeten wordt, wat is uitgezonderd en wat de klant krijgt als je het niet haalt. Niet elke dienst heeft een SLA nodig, maar elke SLA heeft een SLO nodig die erachter staat, anders krijg je geen vroege waarschuwing dat je op het punt staat hem te breken.
Hoe SLI’s, SLO’s en SLA’s samenhangen
Zie ze als lagen. De SLI is het ruwe signaal. De SLO is een strengere interne lijn op dat signaal. De SLA is een ruimere externe lijn op hetzelfde signaal. Een gangbare opzet voor een SaaS-product ziet er zo uit (voorbeeldwaarden):
SLI: aandeel checks per minuut op app.lumenanalytics.io die status 200 teruggeven en de titel van het dashboard bevatten.
SLO: 99,95% per kalendermaand.
SLA: 99,9% per kalendermaand, met een service credit als dat niet wordt gehaald.
Het verschil tussen 99,95% en 99,9% is de veiligheidsmarge. Ziet het team de SLO in week twee wegzakken, dan is er nog tijd om in te grijpen voordat de contractuele belofte in gevaar komt.
Uptimepercentages in minuten
Op papier liggen uptimedoelen dicht bij elkaar, maar elke extra negen deelt de toegestane downtime door tien. De tabel hieronder gaat uit van een gemiddelde maand (een jaar van 365,25 dagen gedeeld door 12), net als de uptimecalculator; een maand van 30 dagen staat iets minder toe.
UptimedoelToegestane downtime per maandToegestane downtime per jaar99%7 u 18 min 18 s3 dagen 15 u 39 min 36 s99,5%3 u 39 min 9 s1 dag 19 u 49 min 48 s99,9 min 49 s8 u 45 min 57 s99,95 min 54 s4 u 22 min 58 s99,99%4 min 22 s52 min 35 s99,999 s5 min 15 s
Daar volgen twee praktische gevolgen uit. Ten eerste moet je monitoring de downtime die je belooft ook kunnen zien. Met checks om de vijf minuten kun je een maanddoel van 99,99% niet eerlijk meten, omdat één gemiste storing het hele budget kan opmaken. Ten tweede laat elk doel boven 99,9% bijna geen ruimte voor handmatig ingrijpen. Bij 99,99% is de maand na één traag nachtelijk incident al verloren.
Error budgets: van SLO naar beslissingen
Een error budget is de hoeveelheid falen die je SLO toestaat. Bij een SLO van 99,9% per maand is het budget 0,1% van de maand, ongeveer 43 minuten en 49 seconden in een gemiddelde maand (43 minuten en 12 seconden in een maand van 30 dagen). Elk incident gebruikt er een deel van.
Het budget maakt van betrouwbaarheid een gezamenlijke beslissing in plaats van een discussie. Een eenvoudig beleid dat veel teams hanteren:
Meer dan de helft van het budget over: release zoals gewoonlijk.
Minder dan de helft over: beoordeel riskante deploys en laat een tweede paar ogen meekijken bij databasewijzigingen.
Budget op: pauzeer feature-releases voor die dienst en werk aan de oorzaken van de laatste incidenten tot het venster opnieuw begint.
Een voorbeeld: harborlabs.dev heeft een SLO van 99,9% per maand voor zijn publieke API. Op de 9e veroorzaakt een slechte deploy 18 minuten aan fouten. Op de 20e zorgt een certificaatprobleem voor nog eens 9. Dan is 27 van de 43 minuten verbruikt, met nog tien dagen te gaan. Het team stelt de volgende schemamigratie uit tot de nieuwe maand, omdat nog één incident van dezelfde omvang het doel zou breken.
SLI’s kiezen voor een website of API
Goede SLI’s beschrijven wat gebruikers ervaren, niet wat je servers voelen. CPU op 90% is geen SLI. Een checkout die mislukt wel. Begin met twee of drie indicatoren per dienst:
Beschikbaarheid: het aandeel checks of requests dat slaagt. Voor een website hoort “slagen” te betekenen: de juiste statuscode en de juiste inhoud, niet alleen een respons.
Latency: het aandeel requests dat sneller antwoordt dan een drempel, bijvoorbeeld 95% onder 800 ms. Met een aandeel kun je makkelijker redeneren dan met een gemiddelde, dat trage uitschieters verbergt.
Correctheid: voor API’s het aandeel responses dat de verwachte velden bevat. Een 200 met een lege body is geen succes.
Meet de paden die ertoe doen. Voor een webshop als northwind.shop zijn dat de checkout en de productpagina’s, niet alleen de gecachete homepage. Voor een API zijn dat de endpoints waarmee klanten integreren, het liefst via een health check endpoint dat de database en andere afhankelijkheden test. Een API-monitor die de body van de respons valideert, maakt van dat endpoint een SLI waarop je kunt vertrouwen.
Wat telt mee voor uptime
De meeste geschillen over SLA’s gaan niet over het getal. Ze gaan over wat meetelt. Leg deze punten vast voordat je een doel publiceert:
Gepland onderhoud. Veel SLA’s sluiten vooraf aangekondigd onderhoud uit, bijvoorbeeld met 72 uur vooraankondiging en een maximum van vier uur per maand. Sluit je het uit, vermeld dan hoe het wordt aangekondigd en stel een grens, anders wordt “onderhoud” een achterdeur.
Gedeeltelijke storingen. Is de dienst plat als inloggen werkt maar de checkout faalt? Leg vast welke onderdelen eronder vallen en of een storing van één onderdeel telt als downtime voor het geheel.
Verminderde prestaties. Bepaal of responses die trager zijn dan een drempel als falen tellen. Doet een pagina er 30 seconden over, dan vinden gebruikers hem plat.
Oorzaken buiten je macht. Netwerkproblemen aan de kant van de klant, misbruik en overmacht worden vaak uitgesloten. Je eigen hostingprovider meestal niet; klanten hebben de dienst bij jou gekocht.
Minimale duur. Sommige SLA’s tellen alleen storingen die langer dan een minuut duren of door meer dan één check zijn bevestigd, wat aansluit bij hoe monitoring storingen bevestigt.
Intern is het vaak verstandig om gepland onderhoud wel mee te tellen in je SLO, ook als de SLA het uitsluit. Gebruikers konden de dienst immers niet bereiken, en de SLO hoort hun ervaring te weerspiegelen.
Een SLA voor klanten schrijven
Een goede SLA is kort en concreet. Die beantwoordt zes vragen: welke dienst, welk doel, hoe gemeten, over welke periode, met welke uitzonderingen, en wat er gebeurt als je het niet haalt. Hier is een voorbeeldclausule die je kunt aanpassen:
Dienst: de webapplicatie van Lumen Analytics op app.lumenanalytics.io
en de publieke API op api.lumenanalytics.io.
Doel: 99,9% beschikbaarheid per maand.
Meting: de beschikbaarheid wordt gemeten met externe checks elke minuut.
Een minuut telt als onbeschikbaar wanneer de dienst een fout (5xx)
of geen respons geeft, bevestigd door een tweede check.
Uitzonderingen: gepland onderhoud dat minstens 72 uur vooraf is
aangekondigd op onze statuspagina (max. 4 uur per maand); problemen
veroorzaakt door het eigen netwerk of de eigen systemen van de klant.
Credits: onder 99,9%: 10% van het maandbedrag.
onder 99,0%: 25% van het maandbedrag.
Klanten vragen credits aan binnen 30 dagen na het einde van de maand.
Leg de SLA lager dan wat je werkelijk haalt. Laat je monitoringhistorie over het afgelopen jaar 99,97% zien, dan is 99,9% beloven realistisch. Wie 99,99% belooft omdat dat beter klinkt, maakt van elk incident een contractueel probleem.
Houd credits in verhouding en het claimproces eenvoudig. Klanten zijn zelden uit op het geld. Ze willen zien dat je de belofte serieus neemt en eerlijk meet.
Meten met externe monitoring
Je eigen logs kunnen geen storing meten waarbij je server het request nooit heeft ontvangen. DNS-storingen, verlopen certificaten, netwerkproblemen en een gecrashte load balancer laten je interne metrics allemaal stil. Daarom hoort SLA-meting van buitenaf te komen, op dezelfde manier waarop klanten je bereiken. Is het idee nieuw voor je, begin dan met wat uptime monitoring is en hoe het werkt.
Een degelijke opzet voor SLA-rapportage:
Check elke minuut. Het interval bepaalt de resolutie van je meting.
Bevestig elke storing met een tweede check. Zo blijft een enkele hapering in het netwerk buiten je downtimecijfers.
Valideer de inhoud. Controleer op een woord of veld dat alleen verschijnt als de dienst werkt.
Bewaar de historie. Je hebt begin- en eindtijden van incidenten nodig voor elke maand waarover je rapporteert.
Publiceer het. Met een statuspagina met uptimehistorie zien klanten dezelfde cijfers als jij.
Uptimecheck regelt dit met uptime monitoring tot elke minuut vanuit Stockholm, Londen en New York, SLA-rapporten per monitor voor deze of vorige maand of de laatste 7, 30 of 90 dagen ten opzichte van je doel, CSV-export voor de maandelijkse SLA-verantwoording, en wekelijkse en maandelijkse rapporten per e-mail. Een statuspagina die aan dezelfde monitors is gekoppeld, laat klanten de uptimehistorie achter je belofte zien.
Uptime is maar één kant van betrouwbaarheid. Hoe snel je incidenten opmerkt en oplost, bepaalt hoeveel van het budget elk incident kost; lees MTTR, MTTA en MTBF uitgelegd voor de kant van de respons.
Checklist: SLI’s, SLO’s en een SLA vaststellen
Zet de gebruikerstrajecten op een rij die ertoe doen: inloggen, checkout, de belangrijkste API.
Definieer per traject één SLI voor beschikbaarheid en, waar het ertoe doet, één voor latency.
Meet een maand of twee voordat je doelen kiest.
Leg de SLO iets onder wat je vandaag haalt, en spreek een beleid voor het error budget af.
Leg de SLA onder de SLO, met duidelijke uitzonderingen en credits die in verhouding staan.
Meet elke minuut van buitenaf en bekijk de cijfers maandelijks.
Meet de uptime die je belooft vanaf de plek waar je klanten staan. Probeer Uptimecheck 14 dagen gratis, geen creditcard nodig.