Het uptimepercentage is de tijd dat een dienst online was, gedeeld door de totale tijd, maal 100. Een maand van 30 dagen telt 43.200 minuten; met 27 minuten downtime is de uptime (43.200 − 27) ÷ 43.200 × 100 = 99,9375%.
De formule is eenvoudig. Een getal krijgen dat je kunt verdedigen is lastiger: je moet bepalen wat de totale tijd is, wat als downtime telt, wat je weglaat en hoe je verschillende onderdelen van een systeem combineert. Deze gids loopt ze een voor een door met voorbeelden en legt daarna uit hoe uptime verschilt van beschikbaarheid en betrouwbaarheid.
Snel een antwoord nodig? De uptimecalculator rekent downtime om naar een percentage en een percentage naar toegestane downtime.
De uptimeformule
Uptime % = (Totale tijd − Downtime) ÷ Totale tijd × 100
Totale tijd en downtime moeten in dezelfde eenheid staan. Minuten zijn voor een maand de praktische keuze, seconden als je meer precisie nodig hebt.
PeriodeMinutenSecondenDag1.44086.400Week10.080604.800Maand van 30 dagen43.2002.592.000Maand van 31 dagen44.6402.678.400Gemiddelde maand (30,4375 dagen)43.8302.629.800Jaar (365,25 dagen)525.96031.557.600
Gebruik de werkelijke lengte van de periode als je over een contract rapporteert, want de meeste SLA’s worden per kalendermaand gemeten. De calculator gebruikt de gemiddelde maand zodat doelen eerlijk te vergelijken zijn; daarom toont hij 99,938% voor dezelfde 27 minuten.
Op basis van checks in plaats van minuten
Bestaan je gegevens uit een lijst met checks in plaats van storingstijden, dan is de uptime het aandeel geslaagde checks:
Uptime % = Geslaagde checks ÷ Alle checks × 100
Met elke minuut een check heeft een maand van 30 dagen 43.200 checks. Als daarvan 40 mislukten, is de uptime 43.160 ÷ 43.200 × 100 = 99,907%. Dit werkt alleen als checks op een vast interval draaien, en elke mislukte check telt als een volledig interval downtime. Met checks om de vijf minuten telt een storing van 30 seconden als vijf minuten of helemaal niet.
Uitgewerkte voorbeelden
Meerdere incidenten in één maand
Een webshop had drie incidenten in een maand van 30 dagen: 12 minuten op de 4e, 7 minuten op de 15e en 24 minuten op de 27e. Tel ze eerst op: 43 minuten. Dan (43.200 − 43) ÷ 43.200 × 100 = 99,9005%. Een maand van 30 dagen met 99,9% staat 43 minuten en 12 seconden toe, dus de webshop bleef binnen het doel, met 12 seconden over.
Gepland onderhoud uitsluiten
Sluit je SLA onderhoud uit, haal de onderhoudstijd dan uit de totale tijd, niet alleen uit de downtime:
Uptime % = (Totale tijd − Onderhoud − Downtime) ÷ (Totale tijd − Onderhoud) × 100
Een voorbeeld: een maand van 30 dagen met een onderhoudsvenster van 2 uur en 30 minuten ongeplande downtime. Zonder onderhoud: (43.200 − 120 − 30) ÷ (43.200 − 120) × 100 = 99,930%. Tel je het onderhoud juist als downtime: (43.200 − 150) ÷ 43.200 × 100 = 99,653%. Dezelfde maand, twee heel verschillende getallen; daarom moet de SLA zeggen welke van toepassing is.
Gepauzeerde monitoring werkt hetzelfde. Als niemand mat, was die tijd online noch offline, en hoort ze niet in het totaal.
De uptime van meerdere onderdelen combineren
De meeste diensten hangen van meer dan één ding af. Hoe je hun uptime combineert, hangt ervan af of ze in een keten staan of redundant zijn.
Onderdelen in een keten
Als elk onderdeel moet werken, vermenigvuldig je hun uptimes. Een site die zowel een appserver met 99,9% als een database met 99,9% nodig heeft, haalt hooguit 0,999 × 0,999 = 99,8%, ervan uitgaande dat ze op verschillende momenten uitvallen. Komt er een betaalprovider met 99,9% bij, dan zakt de checkout naar ongeveer 99,7%. Elke afhankelijkheid die je toevoegt, verlaagt het plafond.
Redundante onderdelen
Als elk van twee onderdelen het werk kan doen, ligt de dienst alleen plat als ze allebei uitvallen. Twee servers met elk 99% geven in theorie 1 − (0,01 × 0,01) = 99,99%. In de praktijk delen ze vaak een netwerk, een deploy of een configuratiefout, waardoor ze vaker samen uitvallen dan de berekening aanneemt. Zie het resultaat als bovengrens, niet als belofte.
Neem geen gemiddelde over monitors
Had de homepage 100% en de checkout 99,0%, dan beschrijft een gemiddelde van 99,5% niets wat klanten hebben ervaren. Rapporteer elk onderdeel apart en leg vooraf vast welke onderdelen samen “de dienst” in je SLA vormen.
Uptime vs beschikbaarheid vs betrouwbaarheid
De drie woorden worden vaak als synoniemen gebruikt. Ze meten verschillende dingen, en als je weet welke je bedoelt, wordt het getal bruikbaarder.
Uptime is het aandeel van de tijd dat de dienst bereikbaar was en antwoordde. Dat is wat de formule hierboven berekent, en wat de meeste SLA’s bedoelen.
Beschikbaarheid is het aandeel van de tijd dat de dienst bruikbaar was: bereikbaar, correct en snel genoeg. Een pagina die 40 seconden nodig heeft om te laden, is online maar niet beschikbaar. Tel je trage of foute antwoorden als mislukt, dan meet je beschikbaarheid.
Betrouwbaarheid is hoe lang de dienst draait zonder uit te vallen, meestal gemeten als MTBF (mean time between failures). Het zegt hoe vaak er iets kapotgaat, niet hoe lang het kapot blijft.
Beschikbaarheid verbindt de twee andere getallen via een klassieke formule:
Beschikbaarheid = MTBF ÷ (MTBF + MTTR)
MTTR is de gemiddelde hersteltijd (mean time to recovery). Een dienst die gemiddeld elke 720 uur uitvalt (één keer per maand) en een uur nodig heeft om te herstellen, heeft een beschikbaarheid van 720 ÷ 721 = 99,86%. De formule laat ook de twee manieren zien om die te verbeteren: minder vaak uitvallen, of sneller herstellen. MTTR, MTTA en MTBF uitgelegd beschrijft hoe je elk ervan meet en verbetert.
Twee diensten met dezelfde uptime kunnen heel anders aanvoelen. Eén storing van 43 minuten per maand en 43 storingen van één minuut per maand geven hetzelfde percentage, maar de tweede verstoort elke dag het werk van je gebruikers. Daarom is het de moeite waard om naast het uptimepercentage ook het aantal incidenten bij te houden.
Veelgemaakte fouten
Van binnenuit meten. Serverlogs kunnen geen verzoek vastleggen dat nooit aankwam. DNS-problemen, verlopen certificaten en netwerkstoringen zie je alleen met externe checks.
Elke hapering meetellen. Eén mislukte check ligt vaak aan het netwerk, niet aan je dienst. Bevestig storingen met een tweede check voordat je ze als downtime telt, anders liggen je cijfers lager dan wat gebruikers ervoeren.
Naar boven afronden. 99,896% is geen 99,9%. Rond naar beneden af als je met een doel vergelijkt, of toon genoeg decimalen om ze uit elkaar te houden.
Te weinig checken. Het checkinterval bepaalt de resolutie. Met een check om de 5 of 10 minuten kun je niet zeggen of je een maand van 99,95% hebt gehaald, die 22 minuten toestaat.
Alleen de homepage checken. Een gecachte homepage kan online blijven terwijl inloggen of de checkout faalt. Monitor de paden waar gebruikers van afhankelijk zijn.
De cijfers zonder spreadsheet
Uptimecheck berekent uptime zoals deze gids beschrijft. Uptime monitoring checkt tot elke minuut vanuit Stockholm, Londen en New York en bevestigt elke mislukte check vanaf een tweede locatie. Uptime is het deel van de periode zonder bevestigde storing; onderhoudsvensters en gepauzeerde tijd tellen niet mee.
Rapporten tonen uptime, downtime en incidenten per monitor voor deze maand, vorige maand of de afgelopen 7, 30 of 90 dagen, afgezet tegen een SLA-doel van 99% tot 99,99%, met een csv-download. Zie rapporten maken met een SLA-doel.
Klantrapporten sturen dezelfde cijfers naar de mensen voor wie je werkt. Zie klantrapporten.
Statuspagina’s tonen klanten 90 dagen uptimegeschiedenis per onderdeel. Zie statuspagina’s.
Wil je weten wat een doel toestaat voordat je je eraan verbindt? Lees wat 99,9% uptime betekent of probeer de SLA- en uptimecalculator.
Stop met uptime met de hand uitrekenen. Probeer Uptimecheck 14 dagen gratis, zonder creditcard.