Monitoraggio di cron job e worker in background tramite heartbeat

In breve: Il monitoraggio HTTP classico non rileverà che è caduto il tuo cron notturno che invia fatture o sincronizza dati. Il pattern heartbeat inverte la direzione della comunicazione - il cron si segnala al monitoraggio, e se non chiama all'ora prevista, ricevi un alert.

Il problema: task in background senza endpoint HTTP

Un backend tipico ha percorsi:

• Richieste web (HTTP/HTTPS al server) - monitori con uptime check.
• Cron job (backup giornaliero, fatturazione mensile, sync oraria) - non hanno endpoint HTTP, il monitoraggio esterno non li vede.
• Worker (Celery, BullMQ, Sidekiq) che consumano una coda - anche senza HTTP.

Se il cron cade (cambi crontab e fai un typo, il server non ha disco, manca una variabile d'ambiente, un upgrade di dipendenza ha rotto l'import), nessuno ti avverte - finché lunedì mattina noti che le fatture non sono state inviate nel weekend.

Pattern heartbeat: il cron pingha il monitoraggio

Il principio è opposto al monitoraggio normale:

1. Nel servizio di monitoraggio crei un monitor heartbeat con intervallo atteso (es. "ogni 60 minuti").
2. Ricevi un URL heartbeat univoco: https://epulz.io/heartbeat/abc123xyz.
3. Nel tuo cron job alla fine di un run riuscito chiami questo URL (HTTP GET o POST).
4. Se il ping non arriva all'ora attesa (+ periodo di grazia), il monitoraggio ti alerta.

Esempio pratico: bash cron

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

La chiave è il && - l'heartbeat viene inviato solo se backup.sh termina con exit code 0. Se lo script fallisce, il ping non arriva, e entro un'ora ricevi un alert.

Suggerimento: Per una copertura più approfondita aggiungi anche un heartbeat "start":

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

Il monitoraggio distingue allora "iniziato e non finito" (script congelato) da "non iniziato affatto" (il cron job non è partito).

Python: requests + try/except

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

def sync_data():
    # la tua logica
    pass

try:
    sync_data()
    requests.get(HEARTBEAT_URL, timeout=10)
except Exception as e:
    # L'heartbeat non viene inviato - il monitoraggio ti alerterà
    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);
});

Periodo di grazia: quanto tempo dare prima dell'alert

Il monitor heartbeat ha bisogno di tolleranza - il cron a volte gira più a lungo del solito, la rete ha latenza, la sync NTP può essere leggermente sfasata. Il periodo di grazia è il tempo dopo l'intervallo atteso durante il quale il monitoraggio attende ancora.

Valori pratici:

• Hourly cron: intervallo 60 min + grazia 10 min
• Daily backup (in media 20 min): intervallo 1440 min + grazia 60 min
• Weekly report: intervallo 10080 min + grazia 360 min (6 h)

Grazia troppo stretta = alert falsi-positivi. Troppo larga = avviso ritardato quando cade davvero.

Dove il pattern heartbeat aiuta di più

• Backup DB notturni
• Sincronizzazione con API esterne (CRM, accounting, payment)
• Calcoli di report
• Task di cleanup (eliminazione di vecchie sessioni, log, file temporanei)
• Ciclo di healthcheck di worker long-running
• Email programmate, newsletter, fatturazione

Conclusione

I task in background sono spesso più critici del web stesso, ma restano un punto cieco del monitoraggio. Il pattern heartbeat richiede 5 minuti di implementazione (aggiungere curl alla fine della riga cron) e fornisce la stessa tranquillità del monitoraggio uptime per il frontend.

Inizia a monitorare i cron job

ePulz.io supporta heartbeat check con periodo di grazia configurabile. 7 giorni gratis.

Avvia monitoraggio →