SLO en SLA voor SaaS-platformen.

SLA, SLO, SLI — de begrippen

In gesprekken over uptime worden de termen SLA, SLO en SLI vaak door elkaar gebruikt. Dat is problematisch, want ze betekenen iets fundamenteel anders. Als je ze door elkaar haalt, beloof je dingen die je niet kunt waarmaken — of je meet dingen die niets zeggen over de ervaring van je klant.

Een SLA (Service Level Agreement) is een contract met je klant. Het beschrijft wat je belooft en wat de consequenties zijn als je die belofte niet nakomt. Denk aan uptime-garanties, responstijden bij storingen en financiele compensatie bij het niet halen van targets. Een SLA is een juridisch document en een commercieel instrument tegelijk.

Een SLO (Service Level Objective) is een interne doelstelling. Het is het getal waar je team op stuurt — strenger dan je SLA, zodat je een buffer hebt voordat je contractuele verplichtingen schendt. Als je SLA 99.9% uptime belooft, stel je je SLO op 99.95%. Zo heb je ruimte om te reageren voordat het een contractueel probleem wordt.

Een SLI (Service Level Indicator) is de daadwerkelijke meting. Het is het getal dat uit je monitoringsysteem komt: het percentage succesvolle requests, de gemiddelde responstijd, de foutpercentages. Zonder betrouwbare SLI's zijn je SLO's en SLA's niets meer dan lege beloftes.

Het onderscheid is cruciaal. Je SLA is wat je klant ziet. Je SLO is waar je team op stuurt. Je SLI is de waarheid. Wanneer die drie niet op elkaar aansluiten, ontstaan er problemen: teleurgestelde klanten, overbelaste teams of onrealistische verwachtingen.

Wat betekent 99.9% uptime eigenlijk?

De meeste SaaS-platformen beloven ergens tussen 99.5% en 99.99% uptime. Dat klinkt allemaal als "bijna altijd beschikbaar", maar de verschillen zijn enorm wanneer je het vertaalt naar daadwerkelijke downtime.

99.9% uptime — het veelgenoemde "three nines" — betekent maximaal 8 uur en 46 minuten downtime per jaar. Dat is zo'n 43 minuten per maand. Klinkt weinig, maar als die 43 minuten vallen op maandagochtend wanneer je klanten hun werkweek starten, merk je het direct in je support-inbox.

99.95% halveert dat naar 4 uur en 23 minuten per jaar. 99.99% — "four nines" — brengt het terug naar 52 minuten per jaar. Het verschil tussen drie en vier nines lijkt klein, maar de technische en financiele investering om dat te bereiken is exponentieel groter. Elk extra nine vereist meer redundantie, snellere failover, betere monitoring en een groter operationeel team.

Wat veel SaaS-aanbieders vergeten: gepland onderhoud telt ook mee. Als je elke maand een half uur downtime hebt voor deployments, eet dat direct in je uptime-budget. Daarom is zero-downtime deployment geen luxe maar een vereiste zodra je serieuze uptime-afspraken maakt.

Een SLA is geen marketingtekst. Het is een belofte met consequenties. Beloof alleen wat je technisch en organisatorisch kunt waarmaken.

Van belofte naar techniek

Een uptime-percentage op papier zetten is makkelijk. Het daadwerkelijk halen vereist bewuste architectuurkeuzes die je vroeg in het ontwikkelproces moet maken. Later toevoegen is altijd duurder en riskanter.

Redundantie op elke laag. Single points of failure zijn de grootste bedreiging voor je uptime. Draai je applicatie in minimaal twee availability zones bij AWS. Als een datacenter uitvalt — en dat gebeurt — neemt de andere het naadloos over. Dit geldt niet alleen voor je applicatieservers, maar ook voor je load balancers, caching-laag en opslag.

Auto-scaling. Pieken in verkeer moeten niet leiden tot downtime. Configureer je infrastructuur zodat er automatisch capaciteit wordt bijgeschakeld wanneer de belasting toeneemt. Met serverless oplossingen zoals Laravel Vapor is dit ingebouwd; bij traditionele hosting configureer je dit via auto-scaling groups.

Health checks en auto-recovery. Je infrastructuur moet zichzelf kunnen genezen. Configureer health checks die onbereikbare instances automatisch vervangen. Een container die vastloopt, moet worden herstart zonder menselijke tussenkomst. Hoe minder je team handmatig hoeft in te grijpen, hoe sneller je herstelt.

Database failover. Je database is bijna altijd de moeilijkste component om redundant te maken. Gebruik managed database-services met automatische failover, zoals Amazon RDS Multi-AZ. Accepteer dat een failover 30-60 seconden kan duren en ontwerp je applicatie zodat die korte onderbreking geen dataverlies veroorzaakt.

CDN voor statische assets. Zet je CSS, JavaScript, afbeeldingen en andere statische bestanden achter een CDN zoals CloudFront. Dit vermindert de belasting op je applicatieservers en zorgt ervoor dat je frontend beschikbaar blijft, zelfs als je backend even hapert.

Monitoring als fundament

Je kunt geen SLO halen die je niet meet. Monitoring is geen nice-to-have; het is het fundament waarop je hele betrouwbaarheidsstrategie rust. Zonder betrouwbare metingen weet je pas dat er iets mis is wanneer je klant belt.

Externe uptime-monitoring. Meet je beschikbaarheid van buitenaf, vanuit meerdere locaties. Tools zoals UptimeRobot, Pingdom of Better Uptime checken je endpoints elke 30 seconden en alarmeren je wanneer iets onbereikbaar is. Dit is je eerste verdedigingslinie en de enige die de werkelijke klantervaring meet.

Error rate tracking. Een applicatie die draait maar 500-errors teruggeeft, is effectief down. Monitor het percentage foutieve responses en stel drempelwaarden in. Stijgt je error rate boven de 1%, dan is er actie nodig — ook al is je server technisch gezien bereikbaar.

Responstijd-percentielen. Gemiddelde responstijden zijn misleidend. Als 95% van je requests in 200ms wordt afgehandeld maar 5% er 8 seconden over doet, heb je een serieus probleem dat je gemiddelde niet laat zien. Meet je p50 (mediaan), p95 en p99. De p99 vertelt je hoe je slechtste ervaringen eruitzien — en dat zijn de ervaringen die klanten onthouden.

Alerting die niet huilebalt. Een monitoringsysteem dat te vaak alarm slaat, wordt genegeerd. Alert fatigue is een reeel risico. Definieer duidelijke drempelwaarden, gebruik escalatieniveaus en zorg dat alleen daadwerkelijk urgente issues je team wakker maken. Een waarschuwing over een langzame query om 3 uur 's nachts is geen reden om iemand uit bed te bellen.

Incident response

Storingen zijn onvermijdelijk. Het verschil tussen een goed en een slecht draaiend SaaS-platform zit niet in het voorkomen van elke storing, maar in hoe je ermee omgaat wanneer het misgaat.

Statuspagina als eerste communicatiemiddel. Gebruik een publieke statuspagina (Statuspage, Instatus of vergelijkbaar) die automatisch wordt bijgewerkt op basis van je monitoring. Klanten moeten zelf kunnen zien of er een storing is, zonder dat ze hoeven te bellen of te mailen. Transparantie wekt vertrouwen — ook als het nieuws slecht is.

Post-mortems zonder schuldvraag. Na elke significante storing schrijf je een post-mortem. Niet om iemand de schuld te geven, maar om te begrijpen wat er misging en hoe je het voorkomt. Een goede post-mortem beschrijft de tijdlijn, de impact, de root cause en de concrete acties die je neemt om herhaling te voorkomen.

Root Cause Analysis. Oppervlakkige fixes lossen niets op. "De server was vol" is geen root cause — de vraag is waarom de server vol liep, waarom je monitoring dat niet eerder oppakte en waarom je auto-scaling niet triggerde. Blijf doorvragen totdat je bij de werkelijke oorzaak bent. De 5-why-methode is simpel maar effectief.

Communicatie tijdens storingen. Stilte is het slechtste wat je kunt doen tijdens een incident. Communiceer vroeg, communiceer vaak en wees eerlijk over wat je wel en niet weet. Klanten accepteren dat dingen kapotgaan. Wat ze niet accepteren is dat ze in het duister tasten over wanneer het is opgelost.

Klanten vergeven downtime. Wat ze niet vergeven is stilte. Communiceer eerlijk, ook als je het antwoord nog niet hebt.

Conclusie

SLA's en SLO's zijn geen juridische formaliteiten die je op een achtermiddag opstelt. Ze zijn de vertaling van je betrouwbaarheidsbelofte naar concrete techniek, meetbare doelen en duidelijke processen. Een getal op papier is waardeloos als je de infrastructuur, monitoring en incident response niet hebt om het waar te maken.

Begin met het definiëren van je SLI's — meet wat er werkelijk toe doet voor je klant. Stel daar realistische SLO's op die strenger zijn dan wat je extern belooft. En investeer in de infrastructuur, tooling en processen die nodig zijn om die doelen consistent te halen. Dat is geen eenmalig project, maar een doorlopende discipline die groeit met je platform.