Indice
La cosa pericolosa di un cron job fallito è che non succede niente. Nessuna pagina di errore, nessun crash, nessun utente arrabbiato — solo un backup che ha smesso di girare tre settimane fa senza dire nulla, un report mai inviato o uno script di pulizia che ha lasciato riempire un disco fino a far cadere la produzione.
Cron di suo non ha nessun sistema di avvisi integrato. Se un job termina con un errore, cron alza le spalle. Se all'ora prevista il server è spento, il job semplicemente non parte e non lascia dietro di sé nulla che te lo faccia sapere. È proprio questo secondo caso che sfugge alla maggior parte dei sistemi di monitoraggio.
Questa guida presenta tre schemi per intercettare entrambi i tipi di errore e spiega come rendere l'avviso impossibile da ignorare, trasformandolo in una vera telefonata con Echobell.
Schema 1: avvisi in caso di errore con un hook sull'exit code
L'approccio più semplice: attivare un webhook ogni volta che il job termina con uno stato diverso da zero.
Per prima cosa crea un canale in Echobell e copia il suo URL webhook. Poi avvolgi il comando cron:
0 3 * * * /opt/scripts/backup.sh || curl -s "https://hook.echobell.one/t/<channel-token>?title=Backup+failed&host=$(hostname)"Se backup.sh va a buon fine, non succede nulla. Se fallisce, Echobell recapita un avviso sul tuo telefono in pochi secondi. I parametri della query diventano variabili del modello, così la notifica può dire esattamente quale job è fallito e su quale host.
Per script più lunghi, un trap ti dà un contesto più ricco:
#!/usr/bin/env bash
set -euo pipefail
notify_failure() {
curl -s -X POST "https://hook.echobell.one/t/<channel-token>" \
-H "Content-Type: application/json" \
-d "{\"job\":\"nightly-backup\",\"host\":\"$(hostname)\",\"line\":\"$1\"}"
}
trap 'notify_failure $LINENO' ERR
# ... la logica del tuo job ...Il limite: funziona solo se lo script parte davvero e fallisce. Se il server è spento, se cron è configurato male o se qualcuno ha commentato la riga durante una sessione di debug, non scatta mai nessun avviso. Ecco perché ti serve anche lo schema 2.
Schema 2: dead man's switch per le esecuzioni mancate
Un dead man's switch ribalta la logica: il job invia un ping a un monitor quando va a buon fine, e il monitor ti avvisa quando quel ping non arriva nei tempi previsti. Così intercetti ogni tipo di guasto — errori, blocchi, server morti e voci di crontab cancellate.
Due opzioni self-hosted molto diffuse funzionano bene con Echobell:
- Healthchecks.io è nato esattamente per questo. Crea un check con la pianificazione del tuo cron e un periodo di tolleranza, poi aggiungi
&& curl -s https://hc-ping.com/YOUR_UUIDin fondo alla riga del crontab. Quando un ping arriva in ritardo, Healthchecks invia un webhook: puntalo sul tuo canale Echobell e un backup saltato diventa un telefono che squilla. - Uptime Kuma include un tipo di monitor "Push" che funziona allo stesso modo: il tuo job chiama un URL push e Uptime Kuma avvisa tramite le sue integrazioni di notifica quando l'heartbeat smette di arrivare.
In entrambi i casi il flusso è: cron job → ping di successo → il monitor si accorge del silenzio → webhook a Echobell → notifica push o chiamata.
Schema 3: controlli su finestra temporale per i job che producono dati
Alcuni job si verificano meglio dal loro output che dall'exit code. Se il tuo ETL notturno deve aver inserito le righe entro le 4 del mattino, un piccolo job di verifica può controllare il numero di righe e chiamare il webhook di Echobell quando i conti non tornano.
Qui ti vengono in aiuto le condizioni di Echobell: puoi inviare un webhook di stato dopo ogni esecuzione e lasciare che sia il canale a decidere quando notificare. Una condizione come status != "ok" tiene silenziose le esecuzioni riuscite, e le variabili di tempo UTC integrate ti permettono di limitare gli avvisi alla finestra in cui il job avrebbe dovuto concludersi.
Rendere l'avviso impossibile da ignorare
Rilevare il problema è solo metà del lavoro. Un avviso di backup fallito che arriva come banner silenzioso alle 3 del mattino equivale, nei fatti, a nessun avviso.
In Echobell ogni canale sceglie il proprio livello di urgenza:
- Normale — una notifica push classica, va bene per i job informativi
- Urgente — supera la Full Immersion di iOS, giusto per i job che qualcuno dovrebbe guardare a breve
- Chiamata — il telefono squilla come per una vera telefonata finché non te ne accorgi
Per i job in cui un errore silenzioso costa soldi veri — backup dei database, cicli di fatturazione, rinnovi dei certificati — imposta il canale su Chiamata. La differenza tra "l'ho visto alle 3" e "l'ho visto alle 9" è esattamente la differenza che fa un avviso con chiamata.
Se la responsabilità di un job è condivisa tra più persone, passa al team il link di iscrizione del canale: tutti quelli che si iscrivono ricevono lo stesso avviso nello stesso momento.
Quale schema conviene usare?
- Hook sull'exit code: si configura in cinque minuti e intercetta gli errori espliciti. Parti da qui.
- Dead man's switch: intercetta anche le esecuzioni mancate e quelle bloccate. Aggiungilo per ogni job la cui assenza ti farebbe davvero male.
- Controlli sui dati su finestra temporale: per le pipeline in cui "è andato a buon fine ma ha prodotto spazzatura" è un rischio concreto.
Si combinano bene: l'hook sull'exit code ti dice che un job è fallito e perché, mentre il dead man's switch garantisce che tu venga a sapere anche dei guasti che non hanno mai avuto modo di segnalarsi da soli.
Configura il tuo primo avviso per i cron in pochi minuti: scarica Echobell, crea un canale e aggiungi un curl al crontab. La prossima volta che un job pianificato muore alle 3 del mattino, il tuo telefono squillerà — e il backup che ripristinerai il prossimo trimestre esisterà davvero.