Per monitorare un cron job, dagli un heartbeat: un URL univoco che il job richiama ogni volta che termina. Un servizio di monitoraggio si aspetta quella richiesta a intervalli regolari. Se non arriva in tempo, perché il job non è partito, si è bloccato o è andato in crash, ricevi un avviso. Basta una riga in più nel crontab.
Questa guida spiega come funzionano gli heartbeat, come aggiungerne uno e come scegliere le impostazioni giuste.
Perché i cron job hanno bisogno di un monitoraggio dedicato
Cron è affidabile nell’avviare i comandi e muto su ciò che succede dopo. Se uno script di backup fallisce alle 02:00, nulla di visibile si rompe. Il sito resta online e i controlli di uptime restano verdi. Lo scopri settimane dopo, quando ti serve il backup e non c’è.
Tipici errori silenziosi:
All’orario pianificato il server era down o in riavvio.
Il crontab è stato sovrascritto durante un deploy o una migrazione del server.
Il comando fallisce sotto cron perché PATH o altre variabili d’ambiente sono diverse da quelle della tua shell.
Lo script parte ma si blocca su un lock, una chiamata di rete o un disco pieno.
Le credenziali sono scadute, quindi il job parte ed esce con un errore che nessuno legge.
Il monitoraggio uptime non può vedere nulla di tutto questo, perché nulla di pubblico si rompe. Un heartbeat funziona al contrario: invece del monitor che controlla il tuo job, è il tuo job che si fa vivo con il monitor.
Come funziona un heartbeat
Crei un monitor heartbeat e ottieni un URL univoco.
Imposti quando il job deve girare, come intervallo (per esempio ogni 24 ore) o con la pianificazione crontab del job stesso, con un certo margine per le esecuzioni lente.
Quando termina, il job richiama l’URL con GET o POST.
Se non arriva nessuna richiesta in tempo, si apre un incidente e partono gli avvisi.
Quando arriva il ping successivo, l’heartbeat torna regolare e ricevi una notifica di ripristino.
I monitor cron di Uptimecheck funzionano così. Accettano la pianificazione crontab nel tuo fuso orario, ricevono i ping di inizio e di fine su un unico monitor, avvisano quando un’esecuzione supera la durata massima e possono registrare l’exit code e l’output del job. Gli avvisi arrivano via email, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhook e notifiche push sul telefono, su ogni piano.
Aggiungere un heartbeat a un crontab
Supponiamo che un backup giri ogni notte alle 02:30:
30 2 * * * /usr/local/bin/backup.sh
Aggiungi il ping dopo il job, concatenato con && in modo che parta solo se il backup riesce:
30 2 * * * /usr/local/bin/backup.sh && curl -fsS -m 10 –retry 3 https://heartbeat.example.com/your-unique-id > /dev/null
Cosa fanno le opzioni di curl:
-f fa fallire curl in caso di errori HTTP invece di considerarli un successo.
-s lo rende silenzioso, e -S mostra comunque gli errori se qualcosa va storto.
-m 10 smette di aspettare dopo 10 secondi, così una rete lenta non blocca mai il job.
–retry 3 riprova in caso di brevi problemi di rete.
Al posto del segnaposto usa l’URL esatto del tuo monitor heartbeat.
Ping dall’interno di uno script
Per gli script più lunghi, metti il ping alla fine dello script stesso, dopo i passaggi che contano:
#!/usr/bin/env bash
set -euo pipefail
pg_dump northwind > /backups/northwind-$(date +%F).sql
gzip /backups/northwind-$(date +%F).sql
curl -fsS -m 10 –retry 3 https://heartbeat.example.com/your-unique-id > /dev/null
Con set -e lo script si ferma al primo comando che fallisce, quindi il ping parte solo se tutto ciò che lo precede ha funzionato.
Altri scheduler
Gli heartbeat non sono limitati a cron. Qualsiasi cosa possa fare una richiesta HTTP può inviare un ping: timer systemd, Utilità di pianificazione di Windows con Invoke-WebRequest di PowerShell, un CronJob di Kubernetes, una pipeline di CI o una funzione pianificata nella tua applicazione.
Scegliere l’intervallo
L’intervallo deve corrispondere alla pianificazione: 24 ore per un job notturno, 1 ora per un job orario. Lascia un margine per la normale variabilità della durata del job. Se un backup di solito dura 20 minuti ma a volte 50, un’ora di margine in più evita i falsi allarmi senza nascondere a lungo un errore reale.
Parti con un margine generoso, osserva per una o due settimane quanto durano davvero le esecuzioni, poi restringilo. Se il tuo monitor accetta direttamente l’espressione crontab, come quello di Uptimecheck, incolla la pianificazione e scegli il fuso orario del server. Gli orari attesi seguono così esattamente la pianificazione e il margine diventa un periodo di tolleranza.
Heartbeat a confronto con altri approcci
Ci sono altri modi per sorvegliare i job pianificati, ognuno con le sue lacune:
Email da cron. Cron può inviare via email l’output dei comandi, ma solo quando il job gira e produce output. Se il job non parte mai, nessuna email. E comunque la maggior parte di queste email resta non letta.
Monitoraggio dei log. Utile per trovare errori, ma un job che non è mai partito non scrive nessuna riga di log da cercare.
Verifica dei risultati. Alcuni team controllano se esiste un file di backup o se una tabella è stata aggiornata. Funziona, ma servono controlli personalizzati per ogni job.
Un heartbeat funziona allo stesso modo per ogni job e intercetta il caso che gli altri non vedono: il job che non è partito affatto.
Job di lunga durata
Per i job che richiedono molto tempo, come backup di grandi dimensioni o migrazioni di dati, invia un ping sia all’inizio sia alla fine. Se arriva il ping di inizio ma non quello di fine, il job si è bloccato o è andato in crash a metà. Così sai dove guardare prima ancora di aprire un file di log.
In Uptimecheck entrambi i ping vanno allo stesso monitor: richiama l’URL con l’aggiunta di /start quando il job inizia e l’URL semplice quando termina. Il tempo che intercorre viene registrato come durata dell’esecuzione e, se imposti una durata massima, ricevi un avviso quando un’esecuzione dura di più.
A cosa dare un heartbeat
Non tutti i job ne hanno bisogno. Dai la priorità ai job di cui noteresti l’errore solo più tardi:
Backup di database e file.
Importazioni ed esportazioni di dati, come feed di prodotti o sincronizzazioni con la contabilità.
Emissione di fatture, rinnovi e job di fatturazione.
Job di rinnovo dei certificati.
Pulizie che evitano che un disco si riempia.
Generazione di report da cui dipendono altre persone.
Dai a ogni job il suo heartbeat. Uno condiviso ti dice che qualcosa non è partito, ma non cosa.
Risolvere un heartbeat mancato
Quando arriva un avviso di heartbeat:
Verifica se cron ha avviato il job. Guarda nel log di cron o di sistema.
Esegui il comando a mano con lo stesso utente usato da cron e leggi l’output.
Controlla l’ambiente. Usa percorsi assoluti oppure imposta PATH all’inizio del crontab.
Controlla le risorse. Un disco pieno o la memoria esaurita fermano molti job. Il monitoraggio dei server mostra disco, RAM e carico al momento dell’errore.
Controlla la rete in uscita. Una modifica al firewall può bloccare il ping anche quando il job funziona. Se il job è girato ma il ping è fallito, l’errore di curl compare nell’output del job.
Reindirizza l’output del job su un file di log, così c’è sempre qualcosa da leggere:
30 2 * * * /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1 && curl -fsS -m 10 https://heartbeat.example.com/your-unique-id > /dev/null
Puoi anche inviare il risultato insieme al ping. In Uptimecheck, terminare l’URL con l’exit code (/0 significa successo, qualsiasi altro valore un errore) indica come si è concluso il job, e il corpo di una POST viene conservato come output del job e mostrato insieme all’avviso. Questa riga invia un ping all’inizio, esegue il job e riporta il suo exit code e l’output:
30 2 * * * curl -fsS -m 10 –retry 3 -o /dev/null https://heartbeat.example.com/your-unique-id/start; /usr/local/bin/backup.sh > /tmp/backup.log 2>&1; curl -fsS -m 10 –retry 3 –data-binary @/tmp/backup.log -o /dev/null https://heartbeat.example.com/your-unique-id/$?
Checklist per il monitoraggio dei cron job
Elenca i job pianificati che contano, su ogni server.
Crea un heartbeat per ogni job.
Invia il ping dopo che il lavoro è riuscito, concatenato con && o alla fine di uno script con set -e.
Imposta l’intervallo in base alla pianificazione, con un margine per le esecuzioni lente.
Registra l’output del job in un file.
Invia gli avvisi a un canale che qualcuno legge, anche di notte per i job critici.
Controlla lo storico degli heartbeat dopo deploy e migrazioni del server.
In sintesi
Cron non ti dice quando un job fallisce. Un heartbeat sì. Una riga di curl per job trasforma gli errori silenziosi in avvisi, e lo storico ti mostra esattamente quando ogni job è girato l’ultima volta.
Gli heartbeat sono inclusi in ogni piano di Uptimecheck, insieme al monitoraggio di uptime, SSL, domini, DNS e server. Provalo gratis per 14 giorni, senza carta di credito.