---
title: "Avvisi per i cron job falliti: ricevi una chiamata quando un job pianificato muore"
description: "I cron job falliscono in silenzio. Scopri tre schemi affidabili per individuare i job pianificati falliti o mai partiti e ricevere una notifica push o una chiamata in pochi secondi."
date: 2026-07-16
author: Nooc
authorAvatarLink: /images/avatars/nooc.webp
authorLink: https://nooc.me
tags:
  - cron job
  - avvisi di errore
  - avvisi con chiamata
  - monitoraggio
  - Webhook
---

# Avvisi per i cron job falliti: ricevi una chiamata quando un job pianificato muore

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](/it).

## 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:

```bash
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](/it/docs/template), 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:

```bash
#!/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](https://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_UUID` in 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](/it/docs/developer/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](/it/docs/conditions) 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](/it/features/call-notifications).

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](/it), 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.