Ping bewijst alleen dat een server reageert op netwerkverkeer. Het zegt niets over of je website, API of certificaat echt werkt. HTTP-monitoring bewijst dat je applicatie het juiste antwoord teruggeeft. HTTPS-monitoring bewijst dat dat antwoord bovendien versleuteld is met een geldig, niet-verlopen certificaat. Als je alleen ping-checks draait, heb je een vals gevoel van zekerheid over wat "up" betekent.
Wat een ping-check echt bewijst
Ping verstuurt een ICMP (Internet Control Message Protocol) Echo Request en wacht op een Echo Reply, volgens RFC 792. Een antwoord bevestigt één ding: de host is bereikbaar op de netwerklaag (Layer 3) en heeft op dat specifieke pakkettype gereageerd.
Dat is alles. Ping weet niet of je webserver draait, weet niet of je database online is en kan niet zien of poort 443 überhaupt openstaat. RFC 1122 zegt dat hosts een ICMP-echoresponder zouden moeten implementeren, maar "zouden moeten" is niet "moeten", en heel wat firewalls en cloud security groups weigeren inkomend ICMP standaard. Dat betekent:
- Een volkomen gezonde webserver kan een ping-check niet doorstaan omdat de netwerklaag ICMP blokkeert, wat je een vals alarm oplevert.
- Een server kan een ping-check doorstaan terwijl Apache, nginx of je app-proces volledig is gecrasht: een valse geslaagde check.
Door beide faalscenario's is ping op zichzelf een zwak signaal. Het is nuttig voor basale netwerkbereikbaarheid tijdens het debuggen van infrastructuur, maar het is nooit ontworpen om een applicatie te valideren.
WarningStandaard AWS security groups (en veel andere cloudfirewalls) blokkeren inkomend ICMP, tenzij je het expliciet openzet. Als je in de cloud alleen op ping-monitoring vertrouwt, monitor je mogelijk helemaal niets.
Wat een HTTP-check echt bewijst
Een HTTP-monitor verstuurt een echt verzoek, meestal GET of HEAD, naar poort 80 en inspecteert het antwoord, volgens de semantiek in RFC 9110 en de berichtsyntaxis in RFC 9112. Een typische check controleert:
- Of de verbinding tot stand komt en er binnen een time-outvenster een antwoord terugkomt.
- Of de statuscode in het verwachte bereik valt (meestal 2xx, soms met toegestane 3xx-redirects).
- Optioneel of de response body een verwacht trefwoord of verwachte tekst bevat.
Dit bewijst dat je webserverproces draait en de verwachte inhoud serveert, een flinke stap vooruit ten opzichte van ping. Maar HTTP-monitoring stopt bij de applicatielaag over platte tekst. Het raakt TLS (Transport Layer Security) helemaal niet, dus het vertelt je niets over of je HTTPS-endpoint, het endpoint dat je bezoekers en browsers daadwerkelijk gebruiken, functioneert.
Een site kan 200 OK teruggeven op poort 80 terwijl de HTTPS-listener op poort 443 volledig kapot is door een verlopen of verkeerd geconfigureerd certificaat. Een monitor die alleen HTTP controleert, meldt al die tijd "up".
Wat een HTTPS-check echt bewijst
HTTPS-monitoring doet alles wat een HTTP-check doet en valideert daarnaast de TLS-laag zoals gedefinieerd in RFC 8446 (TLS 1.3) en geformaliseerd als HTTP-over-TLS in RFC 2818. Een goede HTTPS-check bevestigt:
- Dat de TLS-handshake succesvol wordt afgerond.
- Dat de certificaatketen valideert tegen een vertrouwde root, volgens het X.509-formaat in RFC 5280.
- Dat het certificaat niet verlopen is (en je idealiter dagen van tevoren waarschuwt).
- Dat er een moderne, niet-verouderde protocolversie wordt onderhandeld. TLS 1.0 en 1.1 zijn formeel afgeschaft door RFC 8996, dus een handshake die daarop terugvalt is op zich al een alarmsignaal.
Dit is het enige checktype dat de meest voorkomende oorzaak van onverwachte "site down"-incidenten die geen echte servercrash zijn, opvangt: een verlopen certificaat. Een ping-check ziet het niet. Een HTTP-check op poort 80 ziet het niet. Alleen een check die TLS spreekt met poort 443 ziet het.
Vergelijking in één oogopslag
| Checktype | Bevestigt netwerkbereikbaarheid | Bevestigt dat app/server reageert | Bevestigt juiste status/inhoud | Bevestigt geldig, niet-verlopen TLS-certificaat |
|---|---|---|---|---|
| Ping (ICMP) | Ja | Nee | Nee | Nee |
| HTTP | Ja | Ja | Ja | Nee |
| HTTPS | Ja | Ja | Ja | Ja |
Elke rij verderop in de tabel omvat de rij erboven: een HTTPS-check is in feite een superset van een HTTP-check, die op zijn beurt een superset is van basale bereikbaarheid.
Waarom ping alleen niet genoeg is
Ping is in 1981 ontworpen voor netwerkdiagnostiek, niet voor het valideren van moderne webapplicaties achter TLS. Wie erop vertrouwt als belangrijkste uptimesignaal, laat twee gevaarlijke gaten open:
- Valse positieven doordat ICMP wordt geblokkeerd door een firewall, security group of CDN-edge, waardoor er alerts afgaan voor servers die eigenlijk prima werken.
- Valse negatieven, het veel schadelijkere geval, waarbij de netwerklaag in orde is maar je app, databaseverbinding of certificaat het heeft begeven, en ping de hele storing vrolijk "up" blijft melden.
Wil je weten of een server op het netwerk bestaat, dan volstaat ping. Wil je weten of je klanten je site echt veilig kunnen laden, dan heb je HTTP- en HTTPS-checks nodig die samen draaien, plus een waarschuwing voor het verlopen van je certificaat die ruim op tijd afgaat.
Welke check moet je eigenlijk draaien?
In de praktijk zouden de meeste teams HTTPS-monitoring moeten gebruiken als primaire check voor alles wat klantgericht is, omdat die de volledige stack valideert die een bezoeker ervaart: DNS-resolutie, TCP-verbinding, TLS-handshake, HTTP-respons en inhoud. Ping- en gewone HTTP-checks zijn nog steeds de moeite waard als secundaire diagnostiek: ze helpen je te achterhalen waar een storing optreedt zodra HTTPS-monitoring een incident signaleert.
Een verstandige opzet ziet er zo uit:
- HTTPS-check op je publieke endpoint, die statuscode, responstijd en certificaatverloop controleert: je primaire alert.
- HTTP-check op een intern of niet-TLS-endpoint (health-checkpaden, interne API's) waar TLS geen rol speelt.
- Ping-/poortchecks voor bereikbaarheid op infrastructuurniveau tijdens het troubleshooten, niet als je belangrijkste alerttrigger.
Weet je niet zeker of een site op dit moment überhaupt bereikbaar is? Haal hem dan door onze gratis website-down-checker voor een directe HTTP/HTTPS-statuscheck van buiten je eigen netwerk: een goede eerste stap voordat je in de logs duikt.
Dit goed instellen
Ping-, HTTP- en HTTPS-checks draaien als afzonderlijke, correct geconfigureerde monitors, elk met eigen alertdrempels en waarschuwingen voor certificaatverloop, is precies waar gespecialiseerde uptime monitoring voor bedoeld is. Voor een breder overzicht van hoe uptime-, performance- en SSL-checks samenhangen, zie onze gids websitemonitoring uitgelegd.
Stel gelaagde checks in (ping, HTTP en HTTPS met alerts voor certificaatverloop) voor al je providers vanuit één dashboard met InfraNest-monitoring.
Veelgestelde vragen
#Is HTTPS-monitoring altijd beter dan HTTP-monitoring?
Voor elk endpoint dat je bezoekers via HTTPS bereiken: ja. Een HTTPS-check valideert de TLS-handshake en het verlopen van het certificaat, iets wat een HTTP-check simpelweg niet kan zien. Houd HTTP-checks aan voor interne of niet-TLS-endpoints waar certificaten geen rol spelen.
#Waarom toont mijn ping-check een server als down terwijl de website prima werkt?
De meeste cloudfirewalls en security groups blokkeren inkomend ICMP standaard, waardoor de server nooit op ping antwoordt, ook al is de webserver op poort 80/443 gezond. Dit is een klassieke valse positief. De oplossing is HTTP/HTTPS monitoren in plaats van, of naast, ICMP.
#Kan een HTTP-check op poort 80 een verlopen SSL-certificaat opmerken?
Nee. Een HTTP-check op poort 80 raakt TLS nooit, dus hij kan geen verlopen certificaten, zwakke ciphers of mislukte handshakes op poort 443 detecteren. Alleen een HTTPS-check vangt die op.
#Hoe ver van tevoren moet ik gewaarschuwd worden dat mijn certificaat verloopt?
Bij de meeste monitoringproviders kun je instellen hoe ver van tevoren je een waarschuwing krijgt, meestal ergens tussen een paar dagen en een paar weken voor het verlopen. Controleer de actuele instellingen van je provider en kies een ruime marge, zodat je het certificaat kunt vernieuwen voordat het verloopt.
Probeer het met een gratis tool
Was dit artikel nuttig?
