Monitoring van cron jobs en background workers via heartbeat

Kort: Klassieke HTTP monitoring detecteert niet dat je nachtelijke cron die facturen verstuurt of data synchroniseert is gevallen. Het heartbeat patroon keert de communicatierichting om - de cron meldt zich bij monitoring, en als hij niet op de verwachte tijd belt, krijg je een alert.

Het probleem: background taken zonder HTTP endpoint

Een typische backend heeft paden:

• Web requests (HTTP/HTTPS naar de server) - monitor je met uptime check.
• Cron jobs (dagelijkse backup, maandelijkse facturatie, uurlijkse sync) - hebben geen HTTP endpoint, externe monitoring ziet ze niet.
• Workers (Celery, BullMQ, Sidekiq) die een queue consumeren - ook zonder HTTP.

Als de cron valt (je verandert crontab en maakt een typo, de server heeft geen disk, een environment variable ontbreekt, een dependency upgrade brak de import), waarschuwt niemand je - tot je maandagochtend merkt dat de facturen het weekend niet zijn verstuurd.

Heartbeat patroon: cron pingt monitoring

Het principe is omgekeerd aan normale monitoring:

1. In de monitoring service maak je een heartbeat monitor met verwacht interval (bijv. "elke 60 minuten").
2. Je krijgt een unieke heartbeat URL: https://epulz.io/heartbeat/abc123xyz.
3. In je cron job aan het einde van een succesvolle run roep je deze URL aan (HTTP GET of POST).
4. Als de ping niet aankomt op de verwachte tijd (+ grace periode), waarschuwt monitoring je.

Praktisch voorbeeld: bash cron

# /etc/crontab
0 3 * * * www-data /usr/local/bin/backup.sh && curl -fsS -m 10 \
  https://epulz.io/heartbeat/abc123xyz > /dev/null

De sleutel is de && - de heartbeat wordt alleen verstuurd als backup.sh eindigt met exit code 0. Als het script faalt, komt de ping niet, en binnen een uur krijg je een alert.

Tip: Voor grondiger dekking voeg ook een "start" heartbeat toe:

curl -fsS -m 10 https://epulz.io/heartbeat/abc123xyz/start > /dev/null
/usr/local/bin/backup.sh
EXIT=$?
curl -fsS -m 10 "https://epulz.io/heartbeat/abc123xyz?exit=$EXIT" > /dev/null

Monitoring onderscheidt dan "begonnen en niet afgemaakt" (script bevroor) van "helemaal niet begonnen" (de cron job draaide niet).

Python: requests + try/except

import os, requests
HEARTBEAT_URL = os.environ["HEARTBEAT_URL"]

def sync_data():
    # je logica
    pass

try:
    sync_data()
    requests.get(HEARTBEAT_URL, timeout=10)
except Exception as e:
    # Heartbeat wordt niet verstuurd - monitoring waarschuwt je
    raise

Node.js: async / await

const HEARTBEAT_URL = process.env.HEARTBEAT_URL;

async function nightlyJob() {
  await processInvoices();
  await fetch(HEARTBEAT_URL, { signal: AbortSignal.timeout(10000) });
}

nightlyJob().catch(err => {
  console.error(err);
  process.exit(1);
});

Grace periode: hoeveel tijd geven voor alert

Heartbeat monitor heeft tolerantie nodig - de cron loopt soms langer dan gewoonlijk, het netwerk heeft latency, NTP sync kan licht verschoven zijn. De grace periode is de tijd na het verwachte interval waarin monitoring nog wacht.

Praktische waarden:

• Hourly cron: interval 60 min + grace 10 min
• Daily backup (gemiddeld 20 min): interval 1440 min + grace 60 min
• Weekly report: interval 10080 min + grace 360 min (6 u)

Grace te krap = false-positive alerts. Te ruim = vertraagde waarschuwing als het echt valt.

Waar het heartbeat patroon het meeste helpt

• Nachtelijke DB backups
• Synchronisatie met externe API's (CRM, accounting, payment)
• Rapport berekeningen
• Cleanup taken (oude sessies, logs, tijdelijke bestanden verwijderen)
• Healthcheck cyclus van langlopende workers
• Geplande emails, newsletters, facturatie

Conclusie

Background taken zijn vaak kritieker dan het web zelf, maar blijven een blinde vlek van monitoring. Het heartbeat patroon vereist 5 minuten implementatie (toevoegen van curl aan het einde van een cron regel) en biedt dezelfde gemoedsrust als uptime monitoring voor de frontend.

Begin met monitoren van cron jobs

ePulz.io ondersteunt heartbeat checks met configureerbare grace periode. 7 dagen gratis.

Monitoring starten →