MTTR (mean time to recovery, of repair) is de gemiddelde tijd vanaf het begin van een incident tot de dienst weer werkt. MTTA (mean time to acknowledge) is de gemiddelde tijd vanaf een melding tot iemand bevestigt dat hij ermee bezig is. MTBF (mean time between failures) is de gemiddelde tijd dat een dienst normaal draait tussen twee incidenten. Samen beschrijven ze de betrouwbaarheid: MTBF zegt hoe vaak er iets kapotgaat, MTTA hoe snel je reageert en MTTR hoe lang klanten er last van hebben.
Deze gids behandelt de definities, de formules, een uitgewerkt voorbeeld met cijfers, welke tijdstempels je verzamelt en de praktische aanpassingen die elke metric verbeteren.
De metrics en wat ze meten
MTTR: vier betekenissen, één afkorting
MTTR is de meest geciteerde incidentmetric en ook de meest verwarrende, want de R staat voor iets anders afhankelijk van wie hem gebruikt:
Mean time to repair: vanaf het begin van de reparatie tot de oplossing er staat. Gebruikelijk bij hardware en onderhoud.
Mean time to recovery (of restore): vanaf het begin van de storing tot de dienst weer werkt voor gebruikers. De nuttigste variant voor websites en API’s.
Mean time to respond: vanaf de melding tot het team in actie komt. Ligt dicht bij MTTA.
Mean time to resolve: tot het incident volledig is afgesloten, inclusief de opvolging die voorkomt dat het opnieuw gebeurt.
Geen ervan is fout. Waar het om gaat, is dat je er één kiest, de definitie opschrijft en die consequent gebruikt. Jouw “recovery”-getal vergelijken met het “repair”-getal van een ander zegt niets. In dit artikel betekent MTTR mean time to recovery: vanaf het moment dat de dienst kapotging tot hij weer werkte.
MTTD en MTTA: de reactie vóór de reparatie
MTTD (mean time to detect) is de tijd vanaf het begin van een incident tot de monitoring alarm slaat. MTTA is de tijd vanaf die melding tot iemand hem bevestigt. Beide vallen binnen MTTR, en daarom zijn ze zo belangrijk: niemand kan een probleem oplossen waar hij nog niet van weet.
MTBF: hoe vaak er iets kapotgaat
MTBF is de gemiddelde uptime tussen incidenten. Hoe hoger, hoe beter. Het verwante MTTF (mean time to failure) gebruik je voor dingen die je vervangt in plaats van repareert, zoals schijven; voor online diensten heb je MTBF nodig.
De formules
MTTD = totale tijd van begin incident tot melding / aantal incidenten
MTTA = totale tijd van melding tot bevestiging / aantal incidenten
MTTR = totale tijd van begin incident tot herstel / aantal incidenten
MTBF = totale bedrijfstijd zonder incidenten / aantal incidenten
Beschikbaarheid = MTBF / (MTBF + MTTR)
De laatste regel laat zien waarom beide kanten tellen. Je verbetert de beschikbaarheid door minder incidenten te hebben (hogere MTBF) of door ze korter te maken (lagere MTTR). Ze korter maken is vaak veel goedkoper.
Een uitgewerkt voorbeeld
Hier is een voorbeeldmaand voor een webshop, met vier incidenten. De cijfers zijn verzonnen ter illustratie, maar de tijdstempels zijn het soort dat elke monitoringtool je geeft.
IncidentBeginMeldingBevestigdHersteldDetectieBevestigingHerstelCheckout 50303:1203:1303:1603:191 min3 min7 minAPI-timeouts10:0510:0610:0810:411 min2 min36 minInlogfouten14:3014:3114:4515:021 min14 min32 minZoekfunctie onbereikbaar22:5022:5122:5623:151 min5 min25 min
Pas nu de formules toe:
MTTD = (1 + 1 + 1 + 1) / 4 = 1 minuut.
MTTA = (3 + 2 + 14 + 5) / 4 = 6 minuten.
MTTR = (7 + 36 + 32 + 25) / 4 = 25 minuten.
MTBF: een maand van 30 dagen heeft 43.200 minuten. Min 100 minuten downtime blijft er 43.100 over. Gedeeld door 4 incidenten is de MTBF 10.775 minuten, ongeveer 7,5 dag.
Beschikbaarheid = 10.775 / (10.775 + 25) = 99,77%.
Twee dingen vallen op. De bevestiging van 14 minuten bij het inlogincident trekt de MTTA op van ongeveer 3 naar 6 minuten, dus het is de moeite waard om te vragen waarom niemand die melding oppakte. En met 99,77% zit deze webshop ruim onder een doel van 99,9%, dat maar 43 minuten per maand toestaat. Stel je zulke doelen, lees dan SLA vs SLO vs SLI om te zien hoe ze samenhangen.
Stel je nu dezelfde maand voor met checks elke vijf minuten en geen bevestigingsstap. Detectie kan dan tot vijf minuten duren in plaats van één, wat tot vier minuten aan elk incident toevoegt. De MTTR stijgt van 25 naar wel 29 minuten zonder dat iemand iets anders heeft gedaan.
Welke tijdstempels je verzamelt
Je hebt per incident vier tijdstempels nodig. De meeste komen rechtstreeks uit je monitoring:
Begin: de eerste mislukte check. Externe monitoring legt die vast, ook als je servers niets loggen.
Melding: wanneer de storing werd bevestigd en de melding de deur uitging.
Bevestigd: wanneer iemand zei: “Ik pak het op.” Heb je geen on-calltool, dan werkt een reactie in het incidentkanaal ook; noteer de tijd. In Uptimecheck bevestig je het incident in de app of, met de Slack-app, met een knop in Slack, en de tijd wordt vastgelegd.
Hersteld: de eerste geslaagde check na het incident, ook het moment waarop de herstelmelding verstuurd wordt.
Bij Uptimecheck heeft elk incident een tijdlijn: wanneer het begon, wie wanneer een melding kreeg, bevestigingen (ook met een knop in Slack als je de Slack-app gebruikt), notities en het herstel. MTTA en MTTR worden voor je berekend, en de CSV-export van het rapport geeft per monitor het aantal incidenten, de downtime en het langste incident voor een spreadsheet. Leg vast wat je hebt geleerd in een postmortem.
Een praktische waarschuwing: gemiddelden verbergen uitschieters. Eén incident van zes uur en negen haperingen van een minuut komen gemiddeld uit op ongeveer 37 minuten, en dat beschrijft geen van beide. Kijk naast het gemiddelde ook naar de mediaan en het langste incident, en bespreek de traagste incidenten één voor één.
Zo verkort je de detectietijd
Check elke minuut
Het checkinterval is de bovengrens van je detectietijd. Checks elke minuut op alles wat geld oplevert of klanten bedient, is de goedkoopste verbetering van je MTTR. Gebruik uptime monitoring met een interval van 1 minuut voor elke kritieke pagina en elk kritiek endpoint.
Check wat kapotgaat, niet alleen wat laadt
Incidenten die je monitoring niet ziet, worden ontdekt door klanten, vaak uren later. Valideer de inhoud van belangrijke pagina’s, monitor de API-endpoints waar apps op leunen en voeg heartbeats toe aan geplande jobs. Elk incident dat een klant als eerste meldt, is een gat in je monitoring.
Zo verkort je de bevestigingstijd
Stuur alleen bevestigde meldingen
Trage bevestiging is meestal een vertrouwensprobleem. Als de helft van de meldingen vals alarm is, leren mensen af te wachten. Bevestig elke storing met een tweede check voordat je alarm slaat, en schrap monitors die meldingen sturen waar niemand iets mee hoeft. Onze gids over minder vals alarm behandelt de details.
Stuur meldingen naar het juiste kanaal
Een e-mail om 03:12 wordt om 07:30 gelezen. Stuur kritieke monitors naar een kanaal dat de telefoon van de dienstdoende bereikt en naar een teamchat voor de rest, en houd minder dringende monitors op e-mail. Met Uptimecheck kies je de meldingskanalen per monitor: e-mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks en pushmeldingen op je telefoon, in elk abonnement. Escalatie kan een kanaal 5 tot 60 minuten achterhouden en pas een melding sturen als de storing nog loopt en niemand hem heeft bevestigd.
Maak duidelijk wie verantwoordelijk is
Een melding naar vijf mensen wordt vaak door niemand bevestigd. Wijs per dienst één eigenaar aan en per dienst één persoon die on-call is. Alle anderen krijgen de informatie, niet de verantwoordelijkheid. Met de on-callroosters van Uptimecheck wisselen mensen elkaar af, met uitzonderingen voor een ziektedag of een ruil, en pushmeldingen bereiken wie op dat moment on-call is.
Zo verkort je de hersteltijd
Schrijf runbooks voor bekende storingen
De meeste incidenten herhalen zich. De schijf loopt vol, een workerpool raakt uitgeput, een certificaatverlenging mislukt. Een kort runbook per monitor maakt van een slaperig zoekwerk een checklist:
Runbook: checkout geeft 503
1. Bekijk het serverdashboard: CPU, geheugen, schijf op web-01 en web-02.
2. Controleer de PHP-FPM-status: sudo systemctl status php8.3-fpm
3. Zijn de workers uitgeput: sudo systemctl restart php8.3-fpm
4. Zoek langlopende jobs: ps aux –sort=-%cpu | head
5. Na 10 minuten nog steeds fout? Escaleer naar de lead developer.
Zet de link naar het runbook waar de melding binnenkomt, bijvoorbeeld vastgepind in het incidentkanaal, zodat hij één tik verwijderd is.
Zet oorzaak en symptoom naast elkaar
Als een websitecheck mislukt, is de eerste vraag meestal of de server zonder geheugen, CPU of schijfruimte zit. Met servermetrics naast je uptimechecks wordt die stap een blik in plaats van een SSH-sessie.
Houd terugdraaien eenvoudig
Veel incidenten beginnen met een deploy. Is terugdraaien één commando, dan duurt herstel minuten. Is er een overleg voor nodig, dan duurt het een uur.
Werk de statuspagina vroeg bij
Een statuspagina maakt de storing zelf niet korter, maar wel het deel dat klanten het ergst vinden: niet weten wat er aan de hand is. Hij voorkomt ook dat support wordt overspoeld terwijl het team het probleem oplost. Een statuspagina die aan je monitors gekoppeld is toont het getroffen onderdeel zodra het incident opent; voeg een korte notitie toe over wat je doet en wanneer de volgende update komt.
MTBF verbeteren
Minder incidenten krijg je door te leren van de incidenten die je had. Schrijf na elk serieus incident een blameless postmortem, spreek een of twee actiepunten af en volg ze tot ze klaar zijn. Na een paar maanden komen dezelfde storingen niet meer terug en stijgt de MTBF.
Begin met meten op basis van echte tijdstempels. Probeer Uptimecheck 14 dagen gratis, zonder creditcard.