Hoe vaak moet je je website monitoren?

Het juiste monitoringinterval is het kortste interval dat je SLA vereist en dat je tolerantie voor alertruis toelaat: voor de meeste productiesites is dat 1-5 minuten. Ga alleen naar 30 seconden of minder waar elke minuut downtime directe kosten met zich meebrengt. Controleer je te weinig, dan duren storingen langer voordat iemand ze opmerkt. Controleer je te vaak, dan verspil je budget en probecapaciteit aan overbodige verzoeken en kun je valse alerts krijgen door kortstondige haperingen.

Waarom de keuze van het interval een afweging is, geen instelling

Elke monitoringcontrole heeft een ingebouwde detectievertraging. Als je elke 5 minuten controleert, mis je in het slechtste geval een storing die één seconde na een controle begint en duurt tot de volgende controle, dus volle 5 minuten onopgemerkte downtime. Gemiddeld over veel storingen is de detectievertraging ongeveer de helft van het interval. Een interval van 5 minuten geeft je dus een gemiddelde vertraging van ~2,5 minuut en een maximale vertraging van 5 minuten.

Die vertraging is belangrijk, omdat ze rechtstreeks van je downtimebudget afgaat. Een korter interval voorkomt geen storingen, maar verkleint wel de tijd tussen het begin van een storing en het moment dat jij ervan weet. Dat is vaak het verschil tussen een stille oplossing en een boze e-mail van een klant.

Stem het interval af op je SLA met een downtimeberekening

Als je een specifiek uptimepercentage belooft (of nodig hebt), reken dan terug vanaf het maandelijkse downtimebudget dat daarbij hoort:

Het patroon is eenvoudig: een controle om de 5 minuten kan in z'n eentje het grootste deel van een 99,9%-budget opslokken als één incident traag wordt opgemerkt. Strengere SLA's dwingen dus kortere intervallen af. Reken de cijfers voor je eigen doel door met onze uptimecalculator voordat je je in een contract aan een SLA verbindt. Je belooft al snel een getal dat je monitoringfrequentie in de praktijk niet kan waarborgen.

TipStel je controle-interval niet gelijk aan je volledige downtimebudget. Houd ruimte over voor de tijd die een mens (of een automatische failover) nodig heeft om daadwerkelijk te reageren zodra een alert afgaat.

Wat monitoringproviders in de praktijk bieden

Monitoringproviders hanteren meestal een paar gangbare niveaus, en het is goed om de spreiding te kennen voordat je kiest:

• 5 minuten: de gebruikelijke standaard in het gratis abonnement van de meeste uptime monitoring-tools; prima voor sites met weinig verkeer, blogs en interne tools.
• 1 minuut: een gangbare basis in betaalde abonnementen; een redelijke standaard voor de meeste productiesites en API's.
• 30 seconden of minder: beschikbaar in de hogere abonnementen van de meeste grote monitoringplatforms en als betaalde optie bij cloud-native health checks; bedoeld voor endpoints die direct omzet opleveren.
• 10 seconden: aangeboden als premium- of snelle-intervaloptie bij sommige health-checkdiensten van cloudproviders, tegen meerprijs.

Er bestaat hier geen universele standaard, en providers passen hun prijsniveaus aan. Zie dit dus als bandbreedtes en niet als vaste getallen wanneer je abonnementen vergelijkt.

Waarom vaker controleren niet automatisch beter is

Elke controle om de 10-30 seconden uitvoeren klinkt veiliger, maar heeft echte nadelen:

• Alertmoeheid. Kortstondige netwerkhaperingen, een trage DNS-resolver of één verloren pakket kunnen gedurende één controlecyclus op een storing lijken. De meeste tools vangen dit op door meerdere opeenvolgende mislukkingen te vereisen, vaak vanaf verschillende probelocaties, voordat er een alert afgaat. Precies daarom moet je het interval en de alertdrempel samen afstemmen, niet los van elkaar.
• Kosten en probebelasting. Frequente controles vanuit meerdere regio's vermenigvuldigen het aantal verzoeken op je origin. Voor de meeste sites is dat verwaarloosbaar, maar op schaal telt het op, zeker als je ook synthetische transactiecontroles uitvoert die meer doen dan een simpele GET.
• Afnemende meerwaarde. Van 5 minuten naar 1 minuut gaan verkleint de maximale detectievertraging aanzienlijk. Van 30 naar 10 seconden verkleint die nog verder, maar de absolute tijdwinst is klein, tenzij je op five-nines mikt.

Verschillende controles, verschillende intervallen

Niet elke controle in je stack heeft dezelfde frequentie nodig. Het is gebruikelijk, en verstandig, om het volgende te draaien:

• Een lichte ping- of TCP-controle elke 30-60 seconden voor een snel eerste signaal.
• Een HTTP/HTTPS-controle die statuscode en response body controleert, elke 1-5 minuten. Dit bewijst namelijk dat de applicatie correct serveert, en niet alleen dat de poort openstaat. Zie ping vs HTTP vs HTTPS monitoring voor wat elk type controle precies aantoont.
• Controles op het verlopen van SSL-certificaten dagelijks. Certificaten verlopen niet binnen enkele seconden, dus elke minuut controleren heeft geen zin; zie websitemonitoring uitgelegd voor hoe uptime-, performance- en SSL-controles samenhangen.
• Synthetische controles in meerdere stappen (inloggen, afrekenen, zoeken) minder vaak, elke 5-15 minuten, omdat ze zwaarder en trager zijn dan een simpele ping.

Een praktische vuistregel

Als je geen formele SLA hebt, gebruik dan dit als uitgangspunt: controleer de kernbeschikbaarheid elke 1-5 minuten vanaf minstens twee geografische locaties, vereis twee opeenvolgende mislukkingen voordat er een alert afgaat, en voeg dagelijkse controles toe voor alles wat langzaam verandert, zoals het verlopen van SSL-certificaten of DNS-records. Verhoog de frequentie alleen voor endpoints waar downtime meetbare kosten heeft (afrekenen, inloggen, API-gateways) in plaats van standaard overal het kortste interval toe te passen.

Met monitoring van InfraNest stel je per endpoint intervallen en alertdrempels voor meerdere locaties in. Zo kan je afrekenpagina strakker gecontroleerd worden dan je marketingblog, zonder dat je voor je hele omgeving de maximale frequentie betaalt.

Bereken je eigen downtimebudget met de uptimecalculator en stel daarna je controle-interval zo in dat het dat budget echt beschermt.