Hoe website-uptime-monitoring werkt in 2026

Een dienst die 99,99% uptime haalt, is minder dan 53 minuten per jaar offline. Zak naar 99,9% en je verliest meer dan acht uur. Uptime-monitoring is het kleine stukje infrastructuur dat die minuten opvangt op het moment dat ze gebeuren. Deze gids legt uit hoe het werkt, wat je moet monitoren, hoe vaak je moet controleren en welke fouten een nuttig hulpmiddel veranderen in achtergrondruis.

Wat een uptime-monitor daadwerkelijk doet

Een uptime-monitor draait een kleine lus. Vanaf een server ergens op het openbare internet stuurt het een verzoek naar een doel dat jij aanwijst. Het registreert het antwoord, de statuscode en hoe lang de heen-en-terugreis duurde. Daarna wacht het op het door jou gekozen interval en probeert het opnieuw.

De probe leeft met opzet buiten jouw infrastructuur. Als je vanuit je eigen netwerk zou monitoren, zou je de storingen missen die er van binnenuit prima uitzien maar voor echte gebruikers stuk zijn. Dit is het verschil tussen synthetische monitoring (een externe prober) en real user monitoring (telemetrie van echte bezoekers). De meeste teams gebruiken beide. Uptime-monitoring is de synthetische kant.

Wat je daadwerkelijk kunt monitoren

Moderne uptime-tools dekken meer dan HTTP. De negen probetypes die je in de markt tegenkomt, beantwoorden allemaal een net iets andere vraag.

• HTTP-controles geven een statuscode en een responstijd terug voor elke URL.
• Ping (ICMP) controleert of een host op netwerkniveau reageert.
• SSL controleert hoeveel dagen er nog overblijven op je certificaat.
• DNS verifieert dat A-, AAAA-, MX-, TXT- of NS-records nog steeds naar de verwachte waarden verwijzen.
• TCP-poort controleert of een service luistert op een bepaalde poort, of dat een poort die gesloten zou moeten zijn plotseling openstaat.
• WHOIS bewaakt de registratievervaldatum van je domeinnaam.
• Blacklist controleert of je verzendende IP op Spamhaus, SORBS of vergelijkbare lijsten terecht is gekomen.
• Heartbeat draait de relatie om: jouw taak pingt de monitor, en je krijgt een melding wanneer dat stopt.

Hoe vaak controleren

Controlefrequentie is een afweging tussen nauwkeurigheid en ruis. Een hogere cadans vangt kortere storingen op, maar produceert meer fout-positieven door tijdelijke netwerkhaperingen. Een lagere cadans vlakt ruis af, maar mist de korte storingen die toch meetellen voor je foutbudget.

Een pragmatische standaard: 60 seconden voor HTTP en ping op belangrijke diensten, 5 minuten voor pagina's met lage prioriteit, 15 minuten voor SSL, elk uur voor WHOIS. Ga alleen naar 30 seconden voor diensten waarbij downtime je meetbaar geld per minuut kost. Onder de 30 seconden gaan verbetert je resultaat zelden en leidt vaak tot meldingsmoeheid.

Alertrouting zonder de ruis

Een alert die niemand leest is erger dan helemaal geen alert. Drie regels dekken de behoeften van de meeste teams.

• Stuur DOWN standaard naar één enkel kanaal, bij voorkeur het kanaal dat je team toch al raadpleegt (Slack, Discord, Telegram of e-mail).
• Hanteer een drempelregel van minimaal 3 opeenvolgende mislukkingen voordat er gepiept wordt. Eén gemiste check is ruis. Drie op rij is een signaal.
• Stuur kritieke services via een ondertekende webhook naar een pagingtool (PagerDuty, Opsgenie). Stuur al het overige naar chat. Bevestig incidenten om de pager te stoppen zodra een mens ermee bezig is.

De fouten die monitoringprogrammaʼs om zeep helpen

De eerste fout is alleen de homepage monitoren. Een werkende homepage zegt vrijwel niets over je checkoutflow of de API waarmee je mobiele app praat. Voeg specifieke HTTP-monitors toe voor de URLs die het belangrijkst zijn voor je omzet of voor je supportbelasting.

De tweede fout is stille fan-out. Elke monitor activeert elk kanaal, vervolgens dempt elk teamlid de luidruchtige kanalen, en het echte incident verschijnt in een gedempt kanaal. Definieer één standaardroute, leid uitzonderingen naar specifieke personen, en evalueer je regels elk kwartaal.

Een startersopstelling in 10 minuten

Als je vanaf nul begint, is de praktische volgorde kort. Maak een HTTP-monitor aan op je hoofd-URL met een interval van 60 seconden. Maak een SSL-monitor aan op dezelfde hostname met een waarschuwingsvenster van 30 dagen. Maak één notificatieregel die DOWN naar de chat van je team routeert. Voeg een statuspagina toe als je externe gebruikers hebt die om uptime geven. Voeg heartbeats toe voor de cronjobs die je facturatie, rapporten en back-ups uitvoeren. Je bent nu al verder dan de mediaan onder operators.