Vorige week verloor een Fortune 500-bedrijf naar schatting 14 miljoen dollar in ongeveer zes uur tijd omdat één enkel SSL-certificaat stilletjes was verlopen en niemand het had gemerkt totdat klanten zich op Twitter begonnen te beklagen. De verlengingsmail was wel verzonden. Hij ging naar een gedeelde inbox die de vorige DevOps-lead beheerde. Hij vertrok in maart. Het certificaat verliep op een zaterdag om 02:14 UTC. De on-call engineer van het platformteam kreeg geen page omdat er technisch gezien niets "down" was — de site serveerde nog gewoon verkeer, alleen met een gigantische rode browserwaarschuwing die elke betalende klant wegjoeg.

Dit is geen ongebruikelijk verhaal. Het is de meest voorkomende vermijdbare outage die we zien, en hij heeft niets te maken met cloudarchitectuur of containerorkestratie. Hij gebeurt omdat de meeste teams domeinmonitoring, SSL-monitoring en uptime-monitoring behandelen als drie afzonderlijke problemen die door drie afzonderlijke tools worden opgelost — of, vaker nog, door niemand. Deze gids loopt door de complete 3-laagse stack, wat je op elke laag moet monitoren en hoe je het zo bedraadt dat je nooit meer wordt verrast.

De 3-laagse monitoringstack#

Elk publiek toegankelijk web-property heeft drie onafhankelijke faalmodi die elk "de site is down"-symptomen veroorzaken maar volledig verschillende remediatie vereisen:

Domeinverlopen — je registratie loopt af, de registrar neemt het domein terug en je DNS stopt met resolven. Hersteltijd: uren tot dagen. Kosten: catastrofaal.
SSL-certificaatverlopen — DNS resolveert nog, de server staat nog aan, maar het certificaat is voorbij zijn notAfter-datum. Browsers blokkeren de verbinding. Hersteltijd: minuten als het geautomatiseerd is, uren als het handmatig is.
Uptime / HTTP-failure — DNS resolveert, het cert is geldig, maar de server geeft een 5xx, time-out of is door je hostingprovider doorgestuurd naar een parking page. Hersteltijd: hangt volledig af van de root cause.

De reden dat alle drie de lagen nodig zijn, is dat elke laag een failure opvangt die de andere missen. Uptime-monitoring vertelt je dat de site stuk is — maar pas nadat het SSL-cert al is verlopen en klanten al zijn afgehaakt. Domeinmonitoring vangt het registratieverloop weken voordat het domein daadwerkelijk valt. SSL-monitoring vangt het cert-probleem 30 dagen voordat de browserwaarschuwing verschijnt. Stack alle drie en je hebt gelaagde verdediging; sla er één over en je hebt een gat groot genoeg om een vrachtwagen door te rijden.

Laag 1: monitoring van domeinverlopen#

Domeinverlopen is de meest vermijdbare outage op het internet, en ook de meest gênante. Microsoft heeft het laten gebeuren. Google heeft het laten gebeuren (twee keer). Foursquare deed het. Sorenson Media deed het. Elk hiervan was een outage van meerdere uren, veroorzaakt door een verlopen creditcard of een verlengingsmail die naar de verkeerde inbox ging.

Waarom registrar-mails niet genoeg zijn#

Registrars sturen verlengingsherinneringen. Ze gaan naar het e-mailadres dat in het systeem stond toen het domein werd geregistreerd, wat vaak de persoonlijke Gmail is van een contractor die drie jaar geleden vertrok. En zelfs wanneer het adres klopt, belanden registrar-mails routinematig in spam, en zelfs als ze dat niet doen, lijken ze precies op de phishingmails die zich voordoen als verlengingsmeldingen — dus mensen verwijderen ze.

Auto-renewal is bedoeld om dit op te lossen, maar auto-renewal faalt op drie veelvoorkomende manieren stilzwijgend:

De creditcard in het systeem verloopt.
De kaart wordt geweigerd wegens fraude (jaarlijkse verlengingen zien er ongebruikelijk uit voor uitgevende banken).
De auto-renewal-toggle bij de registrar wordt omgezet tijdens een accountmigratie of een redesign van het controlpanel.

Externe monitoring is de enige betrouwbare backstop.

Hoe monitor je domeinverlopen#

Het protocol is RDAP (de moderne vervanger van WHOIS), met een WHOIS-fallback voor TLD's die nog geen RDAP ondersteunen. Een dagelijkse check is voldoende — verloopdata van domeinen verschuiven niet van minuut tot minuut, en registrars hanteren bovenop wat jij publiceert hun eigen grace-periodes.

# Snelle handmatige check via command line
curl -s "https://rdap.org/domain/example.com" | jq '.events[] | select(.eventAction=="expiration")'

Stop dat in een cronjob en je hebt een basale monitor. Maar je hebt ook alert-thresholds nodig, retry-logica voor tijdelijke WHOIS-failures, en een manier om onderscheid te maken tussen "verlopen" en "verlengd maar de datum is nog niet gepropageerd". Daarom is een gehoste tool meestal sneller dan zelf bouwen.

De 30/14/7/2-dagen alert-cadans#

Stuur alerts op vier momenten: 30 dagen voor verloop (planning), 14 dagen (actie), 7 dagen (escalatie) en 2 dagen (paniek). Frequenter creëert moeheid. Minder frequent laat geen buffer als de eerste alert wordt gemist.

Wat "verlopen" eigenlijk betekent#

Domeinen vallen niet weg op het moment dat ze verlopen. De meeste TLD's hebben een meertraps tijdlijn:

Dag 0–30 na verloop: grace period. Het domein is opgeschort (geen DNS) maar de registrant kan tegen de normale prijs verlengen.
Dag 30–60: redemption period. Verlenging is nog mogelijk maar met een redemption fee van $80–$200.
Dag 60–90: pending delete. Het domein is gelocked en kan niet worden verlengd.
Dag 90+: dropped. Iedereen kan het registreren.

Belandt een domein dat van jou is in redemption, dan ga je er waarschijnlijk voor betalen maar kun je het nog wel terughalen. Eenmaal in pending delete race je tegen professionele drop-catchers. Laat het nooit zover komen.

Nova Uptime heeft een gratis domain expiry checker voor losse lookups, en het dashboard draait dagelijks RDAP op elk gemonitord domein, met de 30/14/7/2-dagen alert-cadans ingebouwd.

Laag 2: SSL-certificaatmonitoring#

SSL-certificaatverloop is met grote afstand de allereerste oorzaak van "de site is down"-outages. Microsoft Teams ging in februari 2020 plat door een verlopen auth-certificaat. Microsoft Azure had in 2021 een outage van meerdere uren door dezelfde oorzaak. Spotify heeft het gedaan. LinkedIn heeft het gedaan. Google Voice heeft het gedaan. De gemene deler: de 90-dagen-rotatiecadans van Let's Encrypt heeft de hele industrie getraind om automatisering te verwachten, en wanneer de automatisering breekt, breekt hij stilzwijgend.

Wat moet je daadwerkelijk monitoren op een certificaat#

Een certificaat heeft meer faalmodi dan alleen notAfter. Een complete monitor checkt:

notBefore en notAfter — het geldigheidsvenster. Alert op 30, 14, 7 en 2 dagen voor notAfter.
Volledigheid van de issuer-keten — je server moet de volledige intermediate chain serveren. Een veelvoorkomende deploybug is alleen het leaf-certificaat sturen; dit werkt in Chrome (dat intermediates cachet) maar breekt in Firefox, mobiele browsers en de meeste API-clients.
Subject- en SAN-match — de Subject Alternative Names van het certificaat moeten de hostname bevatten die wordt opgevraagd. Wildcard-certs zijn prima maar zorg ervoor dat de wildcard daadwerkelijk het subdomein dekt waar je op uitkomt.
Cipher suite en TLS-versie — TLS 1.0 en 1.1 zijn deprecated. TLS 1.2 is de ondergrens; TLS 1.3 heeft de voorkeur. Zwakke ciphers (RC4, 3DES) zouden je check moeten laten falen.
Aanwezigheid van OCSP-staple — heb je OCSP-stapling geconfigureerd en stopt het met werken, dan zie je browserwaarschuwingen zelfs met een geldig cert.

Veelvoorkomende SSL-faalmodi#

Grofweg op volgorde van frequentie, de failures die we in productie zien:

Certificaat verlopen. De auto-renewal-hook is niet afgegaan. De cronjob is gestorven. Verlenging slaagde maar het nieuwe cert werd niet herladen door de webserver.
Intermediate certificaat ontbreekt of fout. Certbot genereert de chain maar een deployscript overschrijft hem, of een reverse proxy is geconfigureerd met ssl_certificate in plaats van ssl_certificate fullchain.pem.
Hostname-mismatch. Cert is uitgegeven voor example.com maar de gebruiker komt op www.example.com en de SAN bevat geen www.
Verkeerd cert geserveerd (SNI-bug). Server host meerdere sites en het default-vhost-cert wordt geserveerd in plaats van het per-site-cert.
Klokverschuiving. Server klok is meer dan een paar minuten verschoven, waardoor geldige certs verlopen of nog-niet-geldig lijken.

Aanbevolen check-frequentie#

Dagelijks is het minimum. Voor revenue-kritische endpoints — payment-API's, login flows, embedded widgets — is uurlijks redelijk. De check is goedkoop (één enkele TLS-handshake per endpoint) dus frequentie is zelden de bottleneck.

Echte cert-rampen#

Het patroon herhaalt zich elk jaar:

Microsoft Teams, februari 2020 — verlopen intern certificaat haalde Teams urenlang uit de lucht tijdens piek-werkuren.
Microsoft Azure, maart 2021 — TLS-cert-verloop veroorzaakte een 14-uur durende outage die authenticatie over meerdere Microsoft-properties raakte.
Spotify, meerdere jaren — verlopen certificaten hebben minstens drie publiek zichtbare outages veroorzaakt.
GitHub status page — op een gegeven moment serveerde de status page zelf een verlopen cert, het soort ironie waar engineers nerveus om lachen.

Geen van deze bedrijven miste het engineering-talent om verloop te voorkomen. Ze misten de gelaagde monitoring die het zou hebben opgevangen. De gratis SSL expiry checker van Nova Uptime doet een single-shot check; het dashboard draait dezelfde check op een schema en alerteert op 30/14/7/2 dagen.

Laag 3: uptime / HTTP-monitoring#

Uptime-monitoring is de laag die alles opvangt wat de eerste twee lagen niet kunnen voorzien: server crashes, mislukte deploys, runaway memory, uitputting van de database connection pool, DDoS, problemen bij de hostingprovider, DNS-misconfiguraties, CDN-cache-poisoning, en de vijftig andere faalmodi die niet in een cert of registrar-record te zien zijn.

Wat te checken#

Een nuttige HTTP-monitor checkt meer dan alleen "kreeg het verzoek 200 terug?" Specifiek:

Statuscode — alles in het 2xx-bereik is gezond, 3xx kan een redirect zijn naar een parking page (verdacht), 4xx en 5xx zijn failures.
Responstijd — een p95-latency die omhoog kruipt is de leading indicator van een database- of CPU-issue.
Inhoud van de response body — check idealiter op een bekende-goede string (een heartbeat-endpoint dat {"status":"ok"} retourneert) zodat je het geval opvangt waarin de server 200 retourneert maar de applicatie is gecrasht en een errorpagina serveert.
Slagen van de TLS-handshake — vouwt een deel van laag 2 in dezelfde check.
Resolutietijd van DNS — een trage DNS-lookup is vaak het eerste teken van een CDN- of upstream-issue.

Waarom multi-region ertoe doet#

Een single-region-monitor is een machine voor vals zelfvertrouwen. Je monitor staat in us-east-1. Je applicatie ook. AWS heeft een regionaal issue. Beide gaan plat. Je monitor rapporteert "site up" omdat de monitor dood is. Multi-region monitoring (of, op zijn minst, cross-region monitoring — monitor in us-west als je app in us-east staat) elimineert deze klasse van false negative.

Vang failure-screenshots#

Wanneer een check faalt, maak een screenshot van de gerenderde pagina. Dit is goud waard tijdens postmortems omdat het exact vastlegt wat de gebruiker zag op het moment van falen — niet wat de logs zeggen dat er gebeurde, niet wat de synthetische monitor denkt dat er gebeurde, maar wat er op het scherm stond. Was het een 502? Een onderhoudspagina? Een leeg wit scherm? Een Cloudflare-challenge? Je weet het in twee seconden in plaats van twee uur.

Multi-channel alerts#

E-mail is noodzakelijk maar niet voldoende. E-mail wordt gebufferd, gebatched en genegeerd. Kritische alerts moeten e-mail omzeilen en een mens direct bereiken. Nova Uptime ondersteunt e-mail, WhatsApp (Baileys, geen kosten per bericht) en outgoing webhooks (HMAC-signed) om te integreren met PagerDuty, Opsgenie, Slack of welke incident-tooling je ook gebruikt.

De volledige stack opzetten met Nova Uptime#

Hier is de praktische setup, end-to-end, ongeveer in de volgorde waarin je het zou doen.

1. Voeg het domein toe#

Plak de URL in het dashboard. Nova Uptime draait een onmiddellijke HTTP-check, een SSL-handshake, een RDAP/WHOIS-lookup voor domeinverloop en een favicon-fetch. Je ziet alle vier de resultaten binnen 60 seconden.

2. Configureer het check-interval#

Free plan: interval van 15 minuten. Pro plan: tot 59 seconden. Agency plan: dezelfde 59-seconden-ondergrens met hogere domein-limieten. Voor de meeste marketingsites zijn 5-minuten-checks prima. Voor payment-API's zijn 59-seconden-checks correct.

3. Verbind WhatsApp#

In Settings → WhatsApp scan je eenmalig de QR-code. Vanaf dat moment kan elke alert worden verstuurd naar je WhatsApp-nummer zonder kosten per bericht (Free plan = 1 nummer, Pro = 3, Agency = 5). WhatsApp-bezorging is sneller en moeilijker te negeren dan e-mail.

4. Voeg CC-mails toe voor het team#

Op de instellingenpagina van elk domein kun je tot 5 CC-mails toevoegen. Dit is de team-distributielijst voor dat specifieke domein — de homepage alerteert misschien de marketing-lead, de API alerteert de on-call engineer.

5. Test alerts met een opzettelijke failure#

Het allerbeste wat je kunt doen na het bedraden van monitoring is hem één keer opzettelijk breken. Wijs een gemonitorde URL naar een hostname die niet bestaat, of trek tijdelijk het cert in, en kijk hoe de alert afgaat. Gaat hij niet af, dan heb je net een config-bug ontdekt op het goedkoopst mogelijke moment.

6. Weet wanneer je moet upgraden#

De free tier dekt 5 domeinen en is genoeg voor persoonlijke projecten en kleine teams. De twee redenen om te upgraden zijn: (a) je bent over de 5 domeinen heen gegroeid, of (b) je hebt check-intervallen onder 15 minuten nodig. Prijsdetails op de pricing-pagina.

Alertstrategie: voorkom moeheid#

De snelste manier om een monitoring-stack te ruïneren is over-alerteren. Na drie false positives in een week begint elke engineer in het team het kanaal te negeren, en heb je nu monitoring met negatieve waarde.

Drie vuistregels:

Tier severity. Domeinverloop-waarschuwingen 30 dagen vooruit zijn informatief — die gaan alleen naar e-mail. SSL-waarschuwingen 7 dagen vooruit zijn warnings — e-mail plus een Slack-kanaal. Site down voor 2+ minuten is critical — WhatsApp, telefoon laten zoemen, de on-call pagen. Stuur niet alles naar elk kanaal.

Pauzeer tijdens gepland onderhoud. Ga je deployen, een database-migratie pushen of een cert rouleren, pauzeer dan de relevante monitor voor het onderhoudsvenster. Nova Uptime heeft per-domein-pauze en een globale "alle notificaties pauzeren"-toggle in Settings. (Monitoring gaat door — alleen notificaties zijn gepauzeerd, dus je kunt de logs achteraf bekijken.)

Rate-limit ongoing-down-alerts. Zodra een domein als down is gerapporteerd, heb je geen notificatie elke minuut nodig. Nova Uptime stuurt de initiële alert, daarna eens-per-uur ongoing reminders (over e-mail en WhatsApp) totdat het domein herstelt. De recovery-alert gaat altijd onmiddellijk af.

Route per kanaal. E-mail is goed voor digests, weekrapporten en informatieve alerts. WhatsApp is goed voor kritische alerts die binnen de komende 5 minuten een mens nodig hebben. Webhooks zijn goed voor automatisering (auto-creëren van PagerDuty-incidents, posten in Slack, runbooks triggeren).

Een paar opvallende cases die het waard zijn om te kennen:

LinkedIn, oktober 2022 — SSL-verloop van meerdere uren op een subdomein dat berichtbezorging raakte. De hoofdsite bleef up; het issue was gemaskeerd totdat klanten het rapporteerden.
Cloudflare, 2021 — een misconfiguratie van de intermediate certificate chain veroorzaakte wijdverbreide problemen voor sites die Cloudflares edge cert service gebruikten. Het leaf-cert was geldig; de chain was incompleet.
GitHub Status, meerdere incidents — de status page zelf heeft op verschillende momenten verlopen certs geserveerd of registratieproblemen gehad. De les is dat meta-monitoring (het ding dat je vertelt wanneer monitoring kapot is) zelf iets is dat gemonitord moet worden.

Setup-checklist#

Loop deze lijst af en je hebt gelaagde verdediging:

Conclusie#

Domeinmonitoring, SSL-alerts en uptime-monitoring zijn geen drie tools die je aan elkaar bout. Ze zijn drie lagen van één defence-in-depth-strategie, en elke monitoring-stack die er maar één of twee afhandelt zal je uiteindelijk laten zitten op het slechtst denkbare moment. Nova Uptime geeft je alle drie in één dashboard met e-mail- en WhatsApp-alerts op het free plan. Meld je gratis aan en monitor tot vijf domeinen in minder dan vijf minuten.

Gerelateerde reading#

Uptime Monitoring voor SaaS-applicaties — multi-tenant monitoring-playbook voor SaaS-teams
DMARC Policy Setup Guide — de email-tegenhanger van domeinmonitoring
Gratis SSL Expiry Checker — single-shot certificaat-analyse
Gratis Domain Expiry Checker — RDAP/WHOIS-lookup met grace-period-status
Gratis Email Health Checker — zorg dat je alert-mails ook echt aankomen

Domeinmonitoring met SSL-alerts: de complete setupgids voor 2026