SLA-monitoring: hoe je 99,9% uptime volgt en rapporteert

«We garanderen 99,9% uptime.» Het is een belofte die de meeste SaaS-bedrijven doen. Hoeveel kunnen dat echt bewijzen? SLA-monitoring verandert die belofte van marketingtekst in een meetbare, rapporteerbare verplichting.

Uptime-SLA’s begrijpen

Wat betekent «99,9% uptime» eigenlijk?

De cijfers klinken indrukwekkend, maar het verschil tussen elke «negen» is groot:

| SLA | Jaarlijkse downtime | Maandelijkse downtime |
|-----|---------------------|------------------------|
| 99% | 3 dagen, 15 uur | 7 uur, 18 min |
| 99,5% | 1 dag, 19 uur | 3 uur, 39 min |
| 99,9% | 8 uur, 46 min | 43 min, 50 sec |
| 99,95% | 4 uur, 23 min | 21 min, 55 sec |
| 99,99% | 52 min, 36 sec | 4 min, 23 sec |

Bij 99,9% heb je minder dan 44 minuten toegestane downtime per maand. Dat omvat gepland onderhoud, onverwachte storingen en gedeeltelijke verslechtering. Het is een krap budget.

SLA vs SLO vs SLI

Deze termen worden vaak door elkaar gehaald:

• SLI (Service Level Indicator) — De metric die je meet: uptimepercentage, response time, foutpercentage.
• SLO (Service Level Objective) — Je interne doel: «De API moet 99,95% van de tijd beschikbaar zijn.»
• SLA (Service Level Agreement) — De contractuele verplichting met financiële gevolgen: «Als uptime onder 99,9% zakt, krijgen klanten servicecredits.»

Je SLO zou strenger moeten zijn dan je SLA. Als je SLA 99,9% belooft, moet je interne doel 99,95% of hoger zijn. Zo heb je marge voordat SLA-schendingen financiële sancties activeren.

Uptime meten

Basisformule

```
Uptime % = ((Totaal minuten - Downtimeminuten) / Totaal minuten) × 100
```

Voor een maand van 30 dagen (43.200 minuten):

• 20 minuten downtime = 99,954% uptime
• 44 minuten downtime = 99,898% uptime (SLA-schending bij 99,9%)
• 120 minuten downtime = 99,722% uptime

Wat telt als downtime?

Hier wordt het nuancevol. Je SLA moet dit duidelijk definiëren:

Telt meestal als downtime:

• Volledige dienstonbeschikbaarheid (5xx-fouten, timeouts)
• Ernstige prestatieverslechtering (response times > 10× normaal)
• Authenticatiefouten die gebruikers de toegang ontzeggen
• Gegevensverlies of corruptie

Meestal uitgesloten:

• Geplande onderhoudsvensters (met voorafgaande kennisgeving)
• Overmacht (natuurrampen, grote internetstoringen)
• Door de klant veroorzaakte problemen (verkeerd geconfigureerde API-calls)
• Derde partijen buiten jullie controle

Leg deze definities vast in je SLA. Dubbelzinnigheid helpt niemand.

Monitoring voor SLA-naleving

Om uptime nauwkeurig voor SLA-doeleinden te volgen:

Vaak checken: 1-minuut- of 30-seconden intervallen geven precieze downtime-metingen. Een interval van 5 minuten betekent dat je downtimemetingen alleen binnen ±5 minuten nauwkeurig zijn — significant als je maandbudget 44 minuten is.

Monitoren vanuit meerdere locaties: Een storing die alleen Europese gebruikers treft, is nog steeds een storing. Multi-regio-monitoring vangt gelokaliseerde problemen.

Uptime per component: je SLA dekt misschien de totale dienst, maar tracking per component helpt zwakke schakels te vinden: «Onze API had 99,99% uptime, maar het webhook-systeem slechts 99,7%.»

Onderhoudsvensters uitsluiten: als je SLA gepland onderhoud toestaat, zorg dat je monitoringtool maintenance windows ondersteunt zodat die perioden niet meetellen tegen uptime.

Een SLA-rapport opbouwen

Essentiële metrics

Elk SLA-rapport moet bevatten:

1. Totaal uptimepercentage — Het hoofdcijfer.
2. Aantal Incident — Hoe vaak de dienst uitviel.
3. Totale downtime — Geaggregeerde minuten/uur onbeschikbaarheid.
4. MTTD (Mean Time to Detect) — Hoe snel je elk probleem merkte.
5. MTTR (Mean Time to Recovery) — Hoe snel elk probleem werd opgelost.
6. Langste enkele Incident — Je ergste storing in de rapportageperiode.
7. Trendvergelijking — Hoe deze periode zich verhoudt tot eerdere perioden.

Rapportagefrequentie

• Maandelijks: standaard voor de meeste SLA-overeenkomsten. Bovenstaande metrics plus een lijst van Incident met tijdstempels en beschrijvingen.
• Kwartaal: business review-formaat. Trends, verbeterinitiatieven en infrastructuurplannen.
• Jaarlijks: strategisch overzicht voor leiding en enterprise-klanten. Jaar-op-jaar-vergelijkingen en betrouwbaarheids-roadmap.

Strategieën voor hoge uptime

Error budget-beheer

Het «error budget»-concept uit Google’s SRE-framework is krachtig. Je error budget is het verschil tussen 100% en je SLO-doel.

Voor een 99,9% SLO over 30 dagen is je error budget 43 minuten.

Binnen budget kun je snel bewegen — vaak deployen, experimenteren, berekende risico’s nemen. Met een laag budget vertraag je — niet-kritieke deployments bevriezen, meer testen, focussen op betrouwbaarheid.

Investeer op de juiste plekken

Niet alle uptime-verbeteringen zijn even waardevol. Focus op:

1. Single points of failure elimineren — Database zonder replica, server zonder failover, DNS-provider zonder backup.
2. Deployment-risico verlagen — Blue-green, canary en geautomatiseerde rollbacks voorkomen storingen door deployments.
3. Detectiesnelheid verbeteren — Snellere detectie betekent kortere storingen. Het verschil tussen 15 seconden en 5 minuten kan SLA-naleving of -schending zijn.
4. Herstel automatiseren — Zelfherstellende systemen die gecrashte processen herstarten, verkeer omleiden en resources automatisch schalen.

Gebruik een Status Page voor transparantie

Een openbare Status Page verbetert uptime niet direct, maar verandert wel hoe klanten je betrouwbaarheid waarnemen:

• Proactieve communicatie tijdens Incident bouwt vertrouwen
• Incidentgeschiedenis toont je track record
• Abonnee-notificaties houden klanten op de hoogte
• Transparantie vermindert supporttickets

Conclusie

SLA-monitoring gaat niet alleen over contractnaleving — het gaat over een cultuur van betrouwbaarheid. Als je uptime rigoureus meet, transparant rapporteert en je error budget bewust beheert, creëer je een feedbacklus die je dienst continu verbetert.

Begin met duidelijke uptimedoelen, nauwkeurige monitoring en eerlijke rapportage. De cijfers volgen.

Volg je SLA met precisie. Gratis beginnen met monitoren — gedetailleerde uptimerapporten, incident-tracking en Status Pages inbegrepen.