Hoe je cronjobs monitort met heartbeats

Cron is uitstekend in het draaien van dingen volgens schema en rampzalig in het je vertellen wanneer het dat niet doet. Een back-up die stopt met draaien gooit zelden een fout die je ziet. Hij doet gewoon stilletjes niets, en je ontdekt het weken later, wanneer je de back-up nodig hebt en die er niet is. Dit is het probleem van stil falen, en precies daarom heeft elke geplande taak die ertoe doet een heartbeat-controle nodig.

Een heartbeat (of "dead man's switch") draait de logica om. In plaats van te waarschuwen wanneer er iets mis is, pingt je taak een monitoring-endpoint wanneer alles in orde is. Komt de verwachte ping niet op tijd, dan waarschuwt de monitor. Geen ping, geen bericht, groot probleem.

Hieronder vijf patronen, van het eenvoudigste tot het meest robuuste. Alle gaan ervan uit dat je een heartbeat-URL hebt uit je monitoringtool.

Patroon 1: De klassieke dead man's switch

De simpelst mogelijke opzet. Je taak roept na afronding de URL aan. Krijgt de monitor binnen het verwachte venster geen bericht, dan waarschuwt hij.

# Dagelijkse back-up om 02:30, ping na afronding
30 2 * * * /usr/local/bin/backup.sh && curl -fsS https://je-monitor/ping/abc123

De && is cruciaal: curl draait alleen als backup.sh eindigt met code 0 (succes). Faalt de back-up, dan wordt er geen ping verstuurd en pikt de monitor het op. De vlaggen -fsS zorgen dat curl bij HTTP-fouten stil faalt, maar echte problemen toch toont.

Zwakte: bevestigt alleen dat het script draaide en met nul eindigde. Slikt het script zijn eigen fouten in en eindigt het toch met nul, dan krijg je een vals "alles in orde".

Patroon 2: Pingen alleen bij echt succes

Maak het successignaal expliciet in plaats van te leunen op het ketenen van exit-codes in de shell. In scripts met meerdere stappen is dat duidelijker.

#!/bin/bash
set -euo pipefail   # bij elke fout luid crashen
run_the_backup
verify_the_backup    # controleer echt of de output bestaat en klopt
curl -fsS https://je-monitor/ping/abc123   # alleen bereikt als al het bovenstaande slaagde

set -euo pipefail betekent dat elk mislukt commando het script afbreekt nog voor de ping. Een echte verificatiestap toevoegen (het back-upbestand bestaat, is groter dan nul bytes) dicht het gat "eindigde met nul, maar deed niets" uit Patroon 1.

Patroon 3: De exit-code wrapper

Wanneer je de taak zelf niet kunt aanpassen (third-party binary, leveranciersscript), wikkel hem dan in. De wrapper signaleert de start, draait de taak en rapporteert de exit-code.

#!/bin/bash
URL=https://je-monitor/ping/abc123
curl -fsS "$URL/start"                  # signaal "ik ben gestart"
/opt/vendor/report-generator            # de taak die je niet beheert
EXIT=$?
curl -fsS "$URL/$EXIT"                   # rapporteer exit-code

Het signaleren van de start laat de monitor ook de looptijd meten en een taak ontdekken die wel startte maar nooit eindigde (vastliep). Het rapporteren van de exit-code laat hem "liep goed" onderscheiden van "liep en faalde".

Patroon 4: Voorwaardelijke ping (ping alleen als het werk zin had)

Sommige taken draaien volgens schema, maar doen het echte werk slechts soms (een queue-processor die de queue vaak leeg vindt). Je wilt geen "ontbrekende heartbeat"-alert wanneer de taak legitiem niets deed. Ping alleen wanneer er echt werk gebeurde, en verruim het schema daarop.

#!/bin/bash
PROCESSED=$(process_queue)
if [ "$PROCESSED" -gt 0 ]; then
  curl -fsS "https://je-monitor/ping/abc123?count=$PROCESSED"
fi

Stel de verwachte periode van de monitor in op de langste realistische tussenpoze tussen echte runs. De prijs is gevoeligheid: een langer venster betekent tragere detectie, dus gebruik dit alleen wanneer onregelmatig werk echt te verwachten is.

Patroon 5: Jitter en grace windows

Echte schema's driften. Een taak ingesteld op 02:00 kan om 02:00:04 starten door belasting, en de looptijd van een dagelijkse taak varieert. Verwacht de monitor de ping precies op het interval, dan maakt normale jitter je onnodig wakker.

De oplossing is een grace-periode: zeg de monitor dat hij na het verwachte tijdstip nog een marge wacht voor hij waarschuwt. Een dagelijkse back-up die meestal 8 minuten duurt, kan een grace window van 20 minuten gebruiken. Je wilt ook wat jitter in de planning zelf, wanneer je veel taken hebt, zodat ze niet op dezelfde seconde dezelfde resource belasten:

# Voeg een kleine willekeurige vertraging toe (0-59s) om taken van 02:00 te spreiden
0 2 * * * sleep $((RANDOM % 60)) && /usr/local/bin/backup.sh && curl -fsS https://je-monitor/ping/abc123

Grace windows zijn het verschil tussen een monitor die je vertrouwt en een die je na het derde valse alarm mute. Stel de grace zo in dat hij comfortabel boven de slechtst denkbare looptijd van de taak uitkomt, niet boven het gemiddelde.

Snel overzicht

Hoe je dit in de praktijk brengt

Begin vandaag nog met Patroon 1 op de belangrijkste taak (back-up, facturatierun, datasync). Voeg verificatie (Patroon 2) en een grace window (Patroon 5) toe zodra je erop gaat vertrouwen. Een uitgebreidere handleiding voor de heartbeat-configuratie vind je in onze gids cronjobs monitoren met heartbeats.

Communiceert je taak met een dienst via een specifieke poort, controleer dan eerst de bereikbaarheid met de gratis poortchecker. En ben je klaar om geplande taken samen met websites en API's op een plek te monitoren, bekijk dan hoe uptime monitoring van ePulz.io werkt - de proefperiode van 7 dagen is gratis, zonder creditcard.