Cronjobbewaking

Probleem met geplande taken

Een wrede eigenschap van crons is dat als ze uitvallen, niemand je daarvan op de hoogte stelt. De webapplicatie blijft gewoon requests serveren, de homepage ziet er prima uit, de monitoring kleurt groen – maar ergens op de server is de nachtelijke backup al twee weken niet meer uitgevoerd. De queue worker is na een deploy gestopt en de openstaande jobs stapelen zich op. De uurlijks synchronisatie verliest stilletjes regels door een rechtenprobleem. Je komt er pas achter als ergens downstream iets stuk gaat – meestal precies wanneer je het het hardst nodig hebt. Het datateam wil een export, support wacht op de mailqueue, ops op de backup. Tegen die tijd is het al te laat.

Standaard uptime monitoring vangt dit niet, want er is simpelweg niets te pingen. Een cron biedt geen HTTP-endpoint, opent geen poort, start geen server. Hij start, draait, eindigt. Als er iets misgaat – is er geen signaal van zijn afwezigheid, totdat je er bewust naar zoekt.

Anti-patroon: heartbeat monitoring

Heartbeat monitoring (ook bekend als een “dead man’s switch” of “cron monitoring”) draait het om. In plaats van wij controleren jouw dienst, rapporteert jouw dienst zich bij ons. Je voegt één regel toe aan de cron – een curl naar een unieke URL die wij genereren – en deze URL registreert elke ping met een timestamp. Wij houden de afwezigheid van deze pings in de gaten. Als de URL niet wordt gepingd binnen het verwachte interval (plus marge), behandelen we het als een gemiste run en sturen we een alert.

Het model is eenvoudig, betrouwbaar en onafhankelijk van programmeertaal. Alles wat een HTTP-verzoek kan doen – kan geïntegreerd worden. Bash via curl, Python via requests, Node via fetch, PHP via curl_init, Task Scheduler op Windows via Invoke-WebRequest, GitHub Actions, Kubernetes CronJobs, Lambda scheduled events – wat dan ook. Geen SDK, geen agent, geen daemon die geïnstalleerd hoeft te worden.

Hoe te configureren

Klik in DiagnoSEO Uptime Monitoring op "Monitor toevoegen" en kies het type "Heartbeat / cron". De tool genereert een unieke URL met token – zoiets als https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9. Stel het verwachte interval in (hoe vaak de job moet draaien, in minuten) en marge (hoeveel vertraging acceptabel is voordat we alarm slaan). Sla op.

Pas nu je cron aan, zodat hij de URL pingt na elke succesvolle run. Drie stijlen, afhankelijk van je omgeving:

# Bash cron - alleen pingen bij succes
0 3 * * * /usr/bin/backup.sh && curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Of als gedeeltelijk succes oké is
0 3 * * * /usr/bin/backup.sh; curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9 > /dev/null

# Python
import requests
def main():
    do_the_work()
    requests.get('https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9', timeout=5)

# GitHub Actions
- name: Notify heartbeat
  if: success()
  run: curl -fsS https://app.diagnoseo.com/tools/uptime-monitoring/hb.php?t=abc123xyz9

Vanaf nu pingt elke succesvolle run ons, en wij registreren de timestamp. Zien wij binnen interval + marge minuten geen ping, dan wordt er automatisch een incident geopend en volgen notificaties naar alle geactiveerde kanalen: Email, Telegram, Slack, Discord, SMS.

Keuze van interval en marge

Het interval moet exact overeenkomen met het job-schema. Nachtelijke backup om 3:00 – interval 1440 minuten (24u). Uurlijks synchroniseren – 60. Een worker die elke 5 min polt – 5.

De marge vangt natuurlijke jitter op. Crons starten niet altijd letterlijk op de nanoseconde – ze worden in de wachtrij gezet, wachten op een vorige run, doen back-off bij tijdelijke foutjes. Een 24-uurs job met 1 uur marge geeft een comfortabel buffer zonder alerts te vertragen. Een 5-minuten pollende worker met 2 minuten marge pakt echte uitval snel, zonder valse positieve meldingen bij een korte onderbreking van 30 seconden. In het algemeen: stel de marge in op 10–50% van het interval, afhankelijk van hoe ‘instabiel’ de job is.

Aanbevolen patronen

• Alleen pingen bij succes. Gebruik && in bash – een run die faalt pingt niet. Wij detecteren het missen van een ping en sturen een alert.
• Ping na elke iteratie van een loop. Voor lang draaiende workers: ping binnen de loop na elke geslaagde unit van werk, niet pas aan het eind. Zo wordt een vastgelopen worker real-time opgespoord.
• Eén heartbeat per logische job, niet per script. Als drie scripts samen een nachtelijke pipeline vormen, ping dan één keer aan het einde van de keten. Dit geeft een helder signaal “is de pipeline in leven”.
• Koppelen met logging. Heartbeat toont dát de job is gestart. Applicatielogs laten zien wát er is gedaan. Samen vormt dat het complete plaatje.

Wat gebeurt er als de heartbeat uitblijft

Een incident wordt geopend zodra de deadline is verstreken. Op het dashboard staat de monitor op rood met de foutmelding "Geen heartbeat ontvangen sinds X minuten". Notificaties worden naar alle ingeschakelde kanalen gestuurd. Als er weer een nieuwe heartbeat binnenkomt schakelt de monitor automatisch terug naar up – hij wordt als actief aangemerkt, het incident wordt gesloten en (indien herstelalerts aanstaan) ontvang je een "terug online"-melding.

Alles krijgt dezelfde behandeling als andere monitors – heatmap, uptime-percentage, historie, tags, zoeken, export. Vanuit het dashboard gezien is een heartbeat monitor gewoon een extra rij, sorteerbaar en filterbaar naast HTTP, ping, poort en API.

Checklist

Monitor toevoegen → type Heartbeat → gegenereerde URL kopiëren → toevoegen aan cron / worker / scheduler → interval en marge instellen → opslaan → klaar. Nu weet je binnen een seconde wanneer een geplande taak stopt met werken – iets dat op de lange termijn één van de meest cruciale monitoring-beslissingen is die je kunt nemen.

Veelgestelde vragen

• Wat is heartbeat- of cron-jobmonitoring?

  Omgekeerde monitoring — jouw geplande taak pingt onze URL telkens wanneer hij succesvol draait. Als we binnen de gestelde tijd niets horen, sturen we een alert. Hiermee los je het probleem van stille fouten op: een kapotte cron job geeft geen foutmelding en triggert geen traditionele uptime-alert.

• Hoe integreer ik een heartbeat-URL in mijn cron?

  Voeg curl -fsS <heartbeat_url> toe aan het einde van je cron-opdracht. Als de opdracht vóór curl faalt, wordt curl niet uitgevoerd en wordt de heartbeat gemist. Je kunt ook pingen aan het begin én eind via verschillende URL's — zo krijg je aparte signalen voor "gestart" en "afgerond".

• Welke grace-periode moet ik instellen?

  Ongeveer 2-3x de gebruikelijke runtime van de taak. Als je dagelijkse backup 30 minuten duurt, stel grace in op 90 minuten — zo is er ruimte voor vertraging zonder valse alerts. Stel bij taken met wisselende duur de marge royaal in en gebruik het dashboard om uitschieters te spotten.

• Kan ik cronjobs monitoren die elk uur draaien?

  Ja — stel het interval in op het gewenste (bijvoorbeeld 60 minuten verwacht, met een grace van 15 minuten). De monitor verwacht minimaal elke 75 minuten een ping. Draait je taak vaker (elke 5 minuten), dan werkt de heartbeat URL ook gewoon — pas simpelweg het interval aan.

• Werkt heartbeat monitoring voor AWS Lambda / serverless?

  Ja. Voeg aan het einde van je Lambda-functie een HTTP-call toe naar de heartbeat-URL. De monitor ziet dit identiek aan een cron heartbeat — dezelfde alerts, dezelfde grace-periode. Handig voor geplande Lambdas waar CloudWatch-alarms geen stille uitvoeringfouten detecteren.