Bij het kiezen van een webhostingprovider worden uptime-cijfers vaak gezien als een belangrijke maatstaf voor betrouwbaarheid. In marketingkoppen worden vaak garanties als 99,9% of 99,99% beschikbaarheid gepromoot. Na meer dan tien jaar ervaring met het beheer van productie-infrastructuur en het controleren van hostingcontracten, kunnen we echter bevestigen dat een uptime-percentage alleen waardevol is als de Service Level Agreement (SLA) en de technische definities in de servicevoorwaarden het ondersteunen.
Inzicht in uptime-garanties en de wiskunde erachter
Een uptime-garantie is een contractuele maatstaf die aangeeft hoeveel procent van de tijd een hostinginfrastructuur volledig toegankelijk moet blijven tijdens een bepaalde factureringscyclus (meestal maandelijks). Om te begrijpen wat deze cijfers in operationele termen betekenen, kun je de daadwerkelijk toegestane downtime voor een standaardmaand van 30 dagen (720 uur) als volgt bekijken:
Zoek jouw domeinnaam
Vind in één klik of jouw ideale domeinnaam nog vrij is. Met of zonder extensie — wij zoeken het direct voor je op.
Domeinnaam vanaf €1 per maand · Ongekend goede service!
- 99,0% uptime: maximaal 7 uur en 12 minuten downtime per maand.
- 99,9% uptime („drie negens”): maximaal 43 minuten en 12 seconden downtime per maand.
- 99,99% uptime („vier negens”): maximaal 4 minuten en 19 seconden downtime per maand.
- 99,999% uptime („vijf negens”): maximaal 26 seconden downtime per maand.
Hoewel 99,9% bijna perfect klinkt, kunnen 43 minuten onvoorziene uitval tijdens piekuren duizenden transacties op een e-commercewebsite verstoren. Bovendien zijn hogere niveaus zoals 99,99% over het algemeen voorbehouden aan redundante VPS-opstellingen, cloud-instances en architecturen met load balancing over meerdere regio’s, in plaats van standaard gedeelde hostingomgevingen.
Hoe providers de uptime meten versus hoe gebruikers deze ervaren
Een belangrijke kloof tussen hostingproviders en klanten ligt in hoe providers monitoren. Hostingproviders monitoren doorgaans de beschikbaarheid van netwerkinterfaces of de status van de hypervisor via ICMP-ping of lokale poortcontroles (bijvoorbeeld door te testen of poort 80/443 lokaal reageert). Ze houden niet noodzakelijkerwijs bij of jouw specifieke applicatielaag geldige reacties retourneert.
Als bijvoorbeeld een MySQL-service crasht of een PHP-proces het beschikbare geheugen uitput, kan je server nog steeds reageren op netwerk-pingcontroles. Wat de SLA-monitor van de provider betreft, is het systeem 100% online, ook al krijgen bezoekers van de site een HTTP 500 Internal Server Error te zien.
Hosting vanaf €1,95 per maand
Razendsnelle Nederlandse SSD hosting met gratis SSL en dagelijkse backups. Eenvoudig overstappen en altijd persoonlijke support.
€1,95 / per maand
Bekijk webhosting →De Service Level Agreement (SLA) ontleed
De Service Level Agreement is het juridisch bindende document dat bepaalt wat er gebeurt wanneer er een storing optreedt. SLA-clausules definiëren uitsluitingen, rapportageperiodes en crediteringsberekeningen die bepalen of je daadwerkelijk financiële compensatie ontvangt.
Veelvoorkomende SLA-uitsluitingen
In SLA’s worden doorgaans expliciete gebeurtenissen genoemd die niet meetellen voor de totale uitvaltijd:
- Gepland onderhoud: Onderhoudsperiodes (vaak gepland buiten de piekuren) zijn expliciet uitgesloten als er 24 tot 48 uur van tevoren een kennisgeving wordt verstrekt.
- Fouten in applicaties en code: Storingen veroorzaakt door aangepaste applicatiecode, beschadigde databasetabellen of verkeerd geconfigureerde webserverbestanden (.htaccess, NGINX-configuraties) zijn uitgesloten.
- Distributed Denial of Service (DDoS)-aanvallen: Storingen veroorzaakt door externe volumetrische aanvallen worden vaak gecategoriseerd onder uitsluitingen wegens overmacht of noodmaatregelen voor netwerkbeveiliging, tenzij er expliciete DDoS-garanties zijn aangeschaft.
- DNS en externe afhankelijkheden: Storingen in DNS-resolvers van derden, externe API-integraties of blokkades bij domeinregistrars vallen buiten de aansprakelijkheid van de host.
De realiteit van compensatie: servicecredits versus omzetverlies
Veel website-eigenaren gaan ervan uit dat een schending van de SLA hen recht geeft op compensatie voor gederfde omzet of imagoschade. In de praktijk zijn SLA-remedies strikt beperkt tot financiële servicecredits die worden verrekend met je volgende maandelijkse hostingfactuur.
Een typisch crediteringsschema werkt als volgt:
- 99,0% tot 99,8% daadwerkelijke uptime: 10% tot 25% tegoed op de maandelijkse kosten.
- 95,0% tot 98,9% daadwerkelijke uptime: 50% tegoed op de maandelijkse vergoeding.
- Werkelijke uptime lager dan 95,0%: 100% tegoed op de maandelijkse vergoeding.
Omdat credits beperkt zijn tot 100% van je maandelijkse hostingkosten, levert een WordPress-hostingpakket van $ 20 per maand je maximaal $ 20 terug, zelfs als een storing van zes uur zou leiden tot duizenden dollars aan gederfde omzet voor een WooCommerce-webwinkel.
Hoe je jouw bedrijfsvoering kunt beschermen en SLA-kredieten kunt claimen
Omdat compensatie vrijwel nooit automatisch wordt toegepast, moeten websitebeheerders specifieke verificatieprotocollen volgen:
- Implementeer monitoring door derden: Vertrouw niet uitsluitend op de statuspagina’s van de provider. Zet externe monitoringdiensten in (zoals UptimeRobot, Datadog of Pingdom) die zijn geconfigureerd om elke 60 seconden HTTP GET-verzoeken uit te voeren vanaf meerdere geografische locaties. Zorg ervoor dat je monitors controleren op een HTTP 200 OK-responsstatus in plaats van een eenvoudige TCP-ping.
- Documenteer elke storing: Sla serverlogs, statusrapporten van derden en responsheaders op tijdens downtime-incidenten. Noteer de exacte starttijd, duur en HTTP-foutcodes.
- Dien SLA-claims onmiddellijk in: De meeste hostingcontracten vereisen dat klanten binnen 5 tot 30 dagen na het incident een formeel SLA-claimticket openen, inclusief extern logboekbewijs met tijdstempel. Als je dit niet binnen deze termijn indient, verlies je je recht op compensatie.
Door inzicht te krijgen in de technische beperkingen van SLA’s en onafhankelijke applicatiemonitoring te implementeren, kun je hostingproviders realistisch beoordelen, leveranciers aansprakelijk stellen en passende redundantie opbouwen voor bedrijfskritische webapplicaties.