Twee richtingen delen één formule. Start bij een SLA-percentage en u krijgt de downtime die het toestaat (dat is onze uptime-rekenhulp). Start bij de downtime die u had, zoals deze pagina doet, en u krijgt het uptimepercentage dat dat opleverde: (venster − downtime) ÷ venster × 100. Wij voegen de twee cijfers toe die een spreadsheet u niet geeft: wat het kostte, en waar de minuten heen gingen.

Deel de downtime door het venster, keer 100. Een storing van 43m 48s in een maand van 30,42 dagen: 2.628 s ÷ 2.628.000 s × 100 = 0,1% downtime — oftewel 99,9% uptime. Twee regels: tel elk incident in het venster op (middel ze niet weg), en meet vanaf het eerste mislukte verzoek tot het geverifieerde herstel.

Twee tot drie negens is de normale bandbreedte voor kleine tot middelgrote productiediensten — 43 minuten tot 7 uur per maand. Drie negens (43m 48s/maand) is het werkpaarddoel: haalbaar met goede hosting, snelle rollbacks en iemand met wachtdienst. Loopt uw maand op tot meer dan 7 uur, dan toont de schadetabel hierboven welk cijfer u levert — en het tijdlijnonderdeel van het resultaat toont waar u het eerst minuten kunt terugwinnen.

Sla de veelgeciteerde „kosten per minuut"-cijfers uit enterprise-onderzoeken over — die middelen banken en bakkerijen tot één getal. Uw plafond is uw eigen rekensom: omzet per uur × uren down, plus de mensen die alles lieten vallen, plus alles wat contractueel is vastgelegd. Het kostenonderdeel van het resultaat rekent dit live door met uw cijfers. Twee kanttekeningen. Sommige onderbroken kopers komen later terug, dus gederfde omzet is een plafond, geen zekerheid. En sommige kosten passen helemaal niet in de spreadsheet: vertrouwen, SEO, de supportachterstand.

Ze tellen zoals u vooraf hebt vastgelegd dat ze tellen — vóór het incident. Gangbare praktijk: een kapot kritiek pad (checkout, inloggen) telt volledig mee, ook als de homepage nog wel laadt; verminderd-maar-werkend telt apart of helemaal niet mee. Leg de definitie vast en pas hem elke keer op dezelfde manier toe. SLA-discussies gaan over deze alinea, niet over de rekensom.

MTTR staat voor mean time to recovery: totale downtime ÷ aantal incidenten. Het is uw krachtigste hefboom, want hem halveren halveert uw downtime zonder dat u ook maar één incident hoeft te voorkomen. MTBF staat voor mean time between failures, oftewel hoe vaak dingen kapotgaan. Dat zit in architectuur en wijzigingsdiscipline, niet in reactiesnelheid. Samen leveren ze de beschikbaarheid: MTBF ÷ (MTBF + MTTR). RTO is de MTTR die u beloofd hebt — hoe lang een storing mag duren voordat het herstelplan gefaald heeft. Test dit vóórdat een incident het voor u doet.

Val eerst de MTTR aan, dan pas de MTBF — sneller herstellen is goedkoper dan minder vaak falen. En binnen de MTTR: val eerst detectie aan, want dat is de enige fase die een tool voor u ronduit kan wegsnijden. In ons uitgewerkte voorbeeld duurde detectie 11 minuten en de fix 4. Controles elke 30 seconden begrenzen de stilte vóór de eerste mislukte controle tot een halve minuut — ze kunnen de aflevering van de waarschuwing of de tijd tot iemand de telefoon opneemt niet verkorten, en daarom krimpt detectie hier met vier minuten, niet met elf. Diagnose krimpt met bewijs (resultaten vanuit meerdere locaties, exacte tijdstempels); de fix zelf krimpt met geoefende rollbacks — dat deel is aan u.

U kunt niet berekenen wat u niet hebt opgemerkt — de herstart om 3 uur ’s nachts in ons juni-overzicht bestaat alleen omdat er iets meekeek. Onafhankelijke monitoring levert de invoer die deze rekenhulp nodig heeft: exacte begin- en eindtijden, van buiten uw eigen infrastructuur. Dat dekt elk incident, ook de incidenten waarbij niemand wakker was. Uptimia controleert vanaf 171+ locaties in 70+ landen — elke 60 seconden bij het Basic-pakket, elke 30 seconden vanaf Professional — en houdt dat overzicht voor u bij.