Website monitoring uitgelegd: uptime, performance en SSL-checks

Website monitoring bestaat eigenlijk uit drie afzonderlijke taken onder één naam: uptime monitoring (is de site bereikbaar?), performance monitoring (is hij snel?) en SSL/verloopmonitoring (wordt hij volgende week nog vertrouwd?) De meeste teams richten alleen de eerste in en worden vervolgens verrast door een traag ladende checkoutpagina of een verlopen certificaat dat geen van beide andere checks had opgemerkt. Het verschil begrijpen, en alle drie draaien, maakt het verschil tussen "we hoorden het van een klant" en "we wisten het als eerste".

Wat is uptime monitoring?

Uptime monitoring beantwoordt één vraag: kan een gebruiker je site of API op dit moment bereiken? Een monitoringdienst stuurt periodiek HTTP(S)-verzoeken (of een kale TCP/ICMP-ping voor niet-webdiensten) naar je endpoint vanaf een of meer locaties en controleert het antwoord.

Een basischeck kijkt naar:

• Connectiviteit: heeft de server überhaupt binnen een time-outvenster gereageerd?
• HTTP-statuscode: een 2xx-antwoord is gezond; 4xx wijst meestal op een probleem aan de clientkant of in de routing; 5xx betekent dat de server zelf faalt.
• Optionele contentcontrole: sommige checks verifiëren ook dat een specifieke tekst of een JSON-veld in het antwoord aanwezig is, zodat je een server opmerkt die 200 OK teruggeeft op een foutpagina.

De valkuil van alleen uptime monitoring is dat een server binnen een seconde 200 OK kan teruggeven terwijl de pagina erachter kapot is, half wordt weergegeven of verouderde gegevens toont. Een statuscode alleen bewijst niet dat de site werkt; het bewijst alleen dat de server antwoordde.

TipVoer uptime checks uit vanuit meer dan één geografische regio als je publiek wereldwijd is. Een check vanuit één regio kan een storing bij een regionale provider of een CDN-edge volledig missen.

Wil je nu direct een eenmalig antwoord, dan vertelt onze gratis is-het-plat-checker je of een site van buitenaf bereikbaar is. Dat is een goede eerste controle voordat je in de monitoringgeschiedenis duikt.

Wat is performance monitoring?

Performance monitoring meet hoe lang een gezond antwoord daadwerkelijk duurt en of die tijd verslechtert. Dat is een ander soort storing dan downtime: de site is online, geeft 200 terug, maar is zo traag dat gebruikers afhaken.

Typische performancesignalen:

• Responstijd / time to first byte (TTFB): hoe lang de server erover doet om gegevens terug te gaan sturen.
• Volledige laadtijd van de pagina: relevant voor synthetische browserchecks die de pagina renderen in plaats van alleen de HTML op te halen.
• Trend in de tijd: één traag antwoord kan ruis zijn; een gestaag stijgende trend over meerdere dagen wijst op een capaciteits- of databaseprobleem in wording.

Synthetische monitoring (gescripte checks die een echte gebruikersactie nabootsen, zoals inloggen of een checkout afronden) zit aan de performancekant van het spectrum. Het vangt problemen op die een gewone uptime-ping nooit ziet, zoals een kapot script van een derde partij dat het renderen van de pagina ophoudt terwijl de server zelf direct reageert.

Wat is monitoring van SSL-certificaten en vervaldatums?

SSL/TLS-certificaten hebben een vaste geldigheidsduur, en browsers weigeren een site botweg zodra het certificaat verloopt: bezoekers zien een harde waarschuwingspagina, geen trage laadtijd. Dit is waarschijnlijk de best te voorkomen categorie storingen, want de vervaldatum is bekend vanaf het moment dat het certificaat wordt uitgegeven.

SSL-monitoring controleert:

• Het aantal resterende dagen tot de vervaldatum, met waarschuwingen ruim voor de deadline, zodat vernieuwen geen paniekwerk op het laatste moment wordt.
• Geldigheid van de keten: dat het certificaat is ondertekend door een vertrouwde root en dat de tussenliggende keten correct wordt aangeboden, niet alleen dat er een certificaat bestaat.
• Overeenkomst met de hostnaam: dat het certificaat daadwerkelijk het aangeboden domein dekt, wat belangrijk is na migraties of wanneer wildcardcertificaten worden vervangen.

Certificaten die via geautomatiseerde systemen zoals Let's Encrypt worden uitgegeven, vernieuwen vaak en verlopen zelden als de automatisering gezond is. Maar automatisering faalt wel degelijk stilletjes, meestal wanneer een renewal-hook na een servermigratie stukgaat. De vervaldatum onafhankelijk van het vernieuwingssysteem monitoren is de enige manier om dat op te merken voordat een klant het doet. We behandelen de afwegingen tussen geautomatiseerde en commerciële certificaten uitgebreider in onze vergelijking Let's Encrypt vs commerciële SSL-certificaten, en de werking van de vertrouwensketen in SSL-certificaten uitgelegd.

Met onze gratis SSL-checktool kun je elk live certificaat steekproefsgewijs controleren: vervaldatum, uitgever en keten.

WarningEen certificaat kan vandaag volledig geldig zijn en morgen toch falen als de vernieuwingsautomatisering weken geleden stilletjes is stukgegaan. Controleer vervaldatums onafhankelijk van het systeem dat het certificaat heeft uitgegeven.

Hoe werken deze drie checks samen?

Afzonderlijk beantwoordt elke check een beperkte vraag. Samen dekken ze het hele traject van "is er iemand thuis" via "is de ervaring acceptabel" tot "laat de browser een bezoeker überhaupt binnen". Een realistisch incident activeert vaak meer dan één check:

• Een databaseconnectiepool raakt uitgeput → responstijden lopen op (performance) → daarna begint de server volledig te time-outen (uptime).
• Een DNS TTL-wijziging verspreidt zich ongelijkmatig → sommige regio's zien de nieuwe server, andere krijgen verouderde antwoorden (uptime, afhankelijk van de regio).
• Een cronjob voor certificaatvernieuwing faalt na een serververhuizing → uptime en performance blijven groen tot precies de vervaldag, waarop de site voor iedereen met een moderne browser feitelijk onbereikbaar wordt (SSL/verloop).

Dat laatste scenario is precies waarom alleen vertrouwen op uptime-pings een vals gevoel van zekerheid geeft. De check slaagt wekenlang elke vijf minuten en faalt dan catastrofaal op een vaste datum die van tevoren bekend was.

Wat moet een goede alertingopzet afdekken?

Een monitoringopzet zou minimaal het volgende moeten combineren:

1. Een uptime/HTTP-check op elk publiek toegankelijk endpoint, vanuit meer dan één regio.
2. Een alert op een drempelwaarde voor de responstijd, niet alleen een binaire up/down-status.
3. Een SSL-verloopalert met genoeg aanlooptijd om in actie te komen: dagen, geen uren.
4. Een openbare of interne statuspagina, zodat stakeholders hetzelfde signaal krijgen als je team, in plaats van het via een supportticket te horen.

De monitoringfunctie van InfraNest voert uptime-, performance- en SSL-verloopchecks uit vanuit één dashboard voor alle providers die je gebruikt, zodat je niet drie losse tools (en drie losse alert-inboxen) aan elkaar hoeft te knopen om het volledige beeld te krijgen. De gegevens gaan bovendien rechtstreeks naar statuspagina's als je die gezondheidsdata openbaar wilt maken.

Richt uptime-, performance- en SSL-verloopchecks in één keer in met InfraNest monitoring: één dashboard, alle providers en geen onverwachte storingen door verlopen certificaten meer.