Een uptime-check haalt op: een monitoringdienst stuurt volgens een vast schema een verzoek naar je website of API en waarschuwt je als het antwoord fout is of uitblijft. Een heartbeat duwt: je job of dienst stuurt bij elke run een verzoek naar de monitoringdienst, en de melding gaat af als dat verzoek niet binnenkomt. Gebruik uptime-checks voor alles wat mensen via het netwerk bereiken, en heartbeats voor werk dat volgens een schema draait of geen publiek adres heeft. De meeste omgevingen hebben allebei nodig.
De twee worden makkelijk door elkaar gehaald, omdat ze allebei eindigen met “een melding als er iets mis is”. Ze zien alleen andere storingen, en wie de ene gebruikt waar de andere nodig is, houdt een blinde vlek over die pas opvalt als er iets kapotgaat.
Zo werkt een uptime-check
De monitoringdienst is de client. Elke minuut, of met het interval dat je kiest, vraagt hij een URL op, pingt hij een host of opent hij een poort, en beoordeelt hij het antwoord: de statuscode, de responstijd, een trefwoord op de pagina, het certificaat. Mislukt de check en bevestigt een tweede check dat, dan krijg je een melding. Dit is een vorm van synthetic monitoring: een robot doet wat een bezoeker zou doen.
Wat hij opmerkt: een site of API die plat ligt, traag is, fouten teruggeeft, de verkeerde inhoud toont of niet werkt door een verlopen certificaat of een DNS-wijziging. Alles waar een bezoeker tegenaan zou lopen.
Wat hij mist: alles wat geen verzoeken beantwoordt. Een back-up die niet draaide, een queue worker die vastliep, een import die om 02:00 mislukte. De website blijft gewoon online, dus elke check slaagt.
Zo werkt een heartbeat
Je job is de client. Je vertelt de monitoringdienst wanneer de job hoort te draaien, en de job roept een unieke ping-URL aan zodra hij klaar is. Is de ping later dan de marge die je kiest, dan krijg je een melding. Het idee is een dodemansknop: stilte is het signaal. Daarom heet heartbeat monitoring ook wel push monitoring of dead man’s switch monitoring.
0 3 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 –retry 3 -o /dev/null https://app.uptimecheck.com/api/hb/your-token
Wat hij opmerkt: jobs die niet startten, voor het einde crashten, op het verkeerde schema draaiden of, met een startping, veel te lang liepen. Met een exitcode in de ping ziet hij ook jobs die wel draaiden maar mislukten.
Wat hij mist: of iemand je dienst kan bereiken. Een job op een server kan vrolijk blijven pingen terwijl de website op diezelfde server elke bezoeker een 502 geeft.
Naast elkaar
Uptime-checkHeartbeatWie stuurt het verzoekDe monitoringdienstJe job of dienstMelding wanneerHet antwoord fout, traag of afwezig isDe ping te laat is of een fout meldtPubliek adres nodigJaNee, alleen uitgaand HTTPSInstellenEen URL, host of poortEen schema, een marge en één verzoek in de jobZietWat bezoekers en API-clients ervarenOf achtergrondwerk draaide en hoe het afliepBlind voorWerk dat geen verzoeken beantwoordtOf iemand de dienst kan bereiken
Wanneer gebruik je een uptime-check
Je homepage en de pagina’s die geld opleveren: checkout, aanmelden, inloggen.
Publieke API’s en webhook-ontvangers, met checks op de statuscode en de JSON die terugkomt.
Een health check endpoint dat bij elk verzoek de database en andere afhankelijkheden test.
Diensten op andere poorten, zoals een mailserver, met een poortcheck.
De vuistregel: als een persoon of een ander systeem het aanroept, check het dan van buitenaf, op dezelfde manier als zij.
Wanneer gebruik je een heartbeat
Cronjobs: back-ups van databases en bestanden, nachtelijke imports en exports, het genereren van rapporten, facturatieruns.
Geplande taken in andere vormen: een geplande taak in Windows, een Kubernetes CronJob, een GitHub Actions-workflow op een schema, een serverless functie met een timer.
Scripts die certificaten vernieuwen en datasynchronisaties tussen systemen.
Alles achter een firewall of NAT dat van buitenaf niet bereikbaar is, maar wel een uitgaand HTTPS-verzoek kan doen.
Langlopende workers
Een queue worker of daemon draait niet volgens een schema, maar kan toch een heartbeat sturen. Ping elke paar minuten vanuit de hoofdlus en geef de monitor een interval in plaats van een cron-expressie. Loopt de lus vast, wordt het proces beëindigd of herstart de server zonder het weer op te starten, dan stoppen de pings en hoor je het. Ping vanuit de lus die het werk doet, niet vanuit een aparte thread, anders blijft een vastgelopen worker melden dat alles in orde is.
Wanneer je allebei nodig hebt
De meeste echte diensten hebben een voordeur en een backoffice. Monitor elk met het middel dat het kan zien:
Een webshop: uptime-checks op de homepage en de checkout, en heartbeats op de nachtelijke orderexport en de databaseback-up.
Een SaaS-product: een uptime-check op het health endpoint van de API, en heartbeats op de queue worker en de job die facturen verstuurt.
Een interne dienst: geen publiek adres, dus een heartbeat vanuit de dienst zelf, plus uptime-checks op de publieke pagina’s die van zijn data afhangen.
Een alternatief is de jobstatus via het health endpoint zichtbaar maken, bijvoorbeeld door de check te laten falen als de laatste back-up ouder is dan 25 uur. Dat werkt, maar het koppelt de uptime van je website aan je back-ups, waardoor een late back-up in je rapporten als downtime van je website verschijnt. Een aparte heartbeat houdt de twee signalen gescheiden, en ook de mensen die elke melding krijgen.
De timing goed instellen
Interval van de uptime-check: elke minuut voor pagina’s die geld opleveren, want het interval is de langste tijd dat je een storing kunt missen. Minder kritieke pagina’s kunnen een langer interval krijgen.
Marge van de heartbeat: langer dan de normale spreiding in het moment waarop de job klaar is. Een back-up die om 03:00 start, 5 tot 20 minuten duurt en aan het eind pingt, heeft minstens 20 minuten marge nodig; met 30 is er ruimte voor een trage nacht.
Maximale looptijd: met een startping krijg je een melding als een run veel langer duurt dan normaal. Een vastgelopen job stuurt ook nooit zijn eindping, maar deze melding komt zodra de limiet verstreken is.
Tijdzone: een cronschema draait in de tijdzone van de server, vaak UTC. Geef de monitor dezelfde, anders verwacht hij de job door de zomertijd twee keer per jaar een uur te vroeg of te laat. De cron-expressietool laat zien wanneer een schema echt draait.
Veelgemaakte fouten
Alleen bij de start pingen. Een job die start en crasht, meldt zich toch. Ping aan het eind, of stuur allebei.
Ook pingen als de job mislukt. backup.sh; curl … pingt wat er ook gebeurde. Gebruik &&, of stuur de exitcode mee zodat een mislukking ook zo gemeld wordt.
Een ping die de job kan laten hangen. Geef curl een timeout en retries (-m 10 –retry 3), zodat een traag netwerk de job niet blokkeert en de ping niet verloren gaat.
Een heartbeat gebruiken voor een publieke site. Een server die naar buiten pingt, bewijst alleen dat hij het internet bereikt, niet dat bezoekers hem bereiken.
De cron-daemon monitoren in plaats van de job. De daemon kan prima draaien terwijl één job elke nacht mislukt. Elke job die ertoe doet, krijgt een eigen heartbeat.
Meer over de heartbeatkant in cronjobs monitoren en gemiste cron-taken voorkomen.
Allebei op één plek met Uptimecheck
Uptimecheck draait beide soorten monitors in hetzelfde account, met dezelfde meldingskanalen en dezelfde incidentgeschiedenis.
Uptime monitoring: HTTP(S)-, ping- en poortchecks tot elke minuut vanuit Stockholm, Londen en New York, waarbij elke storing vanaf een tweede locatie wordt bevestigd voordat je een melding krijgt. HTTP-checks kunnen de statuscode, een trefwoord, JSON-velden en headers controleren.
Cronjob-monitoring: een crontab-expressie in je eigen tijdzone, zomertijd inbegrepen, of een eenvoudig interval; een marge van 1 minuut tot 6 uur; /start-pings met een maximale looptijd van 1 minuut tot 24 uur; /fail of de exitcode om te melden hoe een run afliep; en de output van de job, meegestuurd met de ping, zichtbaar in de melding.
Limieten: Start bevat 15 uptime-monitors en 10 cronjobs, Professional 100 en 50, Business 250 en 150. Zie prijzen.
Wil je er een instellen? Lees een cronjob monitoren met een heartbeat en de ping-voorbeelden voor cronjobs voor Laravel, Kubernetes, GitHub Actions, systemd en Windows. Voor schijven en geheugen van de server eronder voeg je servermonitoring toe.
Houd de voordeur én de backoffice in de gaten. Probeer Uptimecheck 14 dagen gratis, zonder creditcard.