Cron job: cosa sono e come si usano
Cosa sono i cron job, come si legge la sintassi crontab, dove configurarli su server e piattaforme cloud e gli errori che li fanno fallire in silenzio.
Ogni sistema che funziona da solo ha, da qualche parte, qualcosa che parte a un orario stabilito: il backup notturno, l'email di riepilogo del lunedì, la pulizia dei file temporanei. Il meccanismo che li fa scattare esiste da decenni e si chiama cron. In questo articolo ti spiego come si legge la sua sintassi, dove si configura oggi e — soprattutto — perché così spesso smette di funzionare senza che nessuno se ne accorga.
Cosa sono
Un cron job è un'attività pianificata che il sistema esegue automaticamente a intervalli regolari. Il nome viene da cron, il servizio dei sistemi Unix che si occupa di far partire i comandi all'orario previsto.
Il principio è semplice: dici al sistema cosa eseguire e quando, e da lì in avanti se ne occupa lui.
La sintassi
È la parte che spaventa, e in realtà sono solo cinque numeri in fila:
* * * * * comando da eseguire
│ │ │ │ │
│ │ │ │ └─ giorno della settimana (0-6, 0 = domenica)
│ │ │ └──── mese (1-12)
│ │ └─────── giorno del mese (1-31)
│ └────────── ora (0-23)
└───────────── minuto (0-59)
L'asterisco significa "ogni". Qualche esempio concreto:
| Espressione | Quando |
|---|---|
0 3 * * * | Ogni giorno alle 3:00 |
*/15 * * * * | Ogni 15 minuti |
0 9 * * 1 | Ogni lunedì alle 9:00 |
0 0 1 * * | Il primo del mese a mezzanotte |
30 8 * * 1-5 | Dal lunedì al venerdì alle 8:30 |
0 */6 * * * | Ogni 6 ore |
I tre operatori da conoscere: */n per "ogni n", a-b per un intervallo, a,b,c per un elenco di valori.
Un consiglio pratico: esistono siti che traducono un'espressione cron in linguaggio naturale. Usarli per verificare prima di mettere in produzione evita l'errore classico di far partire ogni minuto qualcosa che doveva girare una volta al giorno.
Dove si configurano
Il posto cambia a seconda di dove gira il tuo progetto.
Su un server Linux o un VPS. Si usa crontab -e per aprire l'elenco delle attività dell'utente e aggiungere le righe. È il metodo classico.
Su un hosting condiviso. Quasi tutti i pannelli di controllo hanno una sezione dedicata con un modulo grafico: scegli l'orario e il comando, senza toccare la riga di comando.
Su piattaforme cloud e serverless. Vercel, Netlify, Cloudflare e simili offrono attività pianificate che chiamano una funzione a orari stabiliti, configurate in un file del progetto. È l'approccio più comune per i progetti moderni — vedi come fare il deploy di un sito.
Servizi esterni. Piattaforme che chiamano un tuo indirizzo a intervalli regolari. Utili quando il tuo hosting non offre pianificazione, e hanno il vantaggio di avvisarti se l'esecuzione fallisce.
Dentro le piattaforme di automazione. Zapier, Make e n8n hanno tutti un innesco a tempo: è il modo più semplice per chi non vuole scrivere codice, e copre gran parte dei casi descritti in automazioni utili per freelance e PMI.
A cosa servono
Gli usi più comuni:
- Backup automatici di database e file — vedi come fare il backup di un sito web
- Pulizia periodica: file temporanei, sessioni scadute, log vecchi
- Email programmate: riepiloghi, promemoria, newsletter
- Sincronizzazioni tra sistemi diversi
- Aggiornamento di dati da fonti esterne
- Controlli di stato: verificare che un servizio risponda
- Elaborazioni pesanti spostate di notte, quando il carico è basso
- Rinnovi automatici di certificati
Gli errori che li fanno fallire
Qui sta la parte utile, perché un cron job che non funziona è insidioso: non dà errore, semplicemente non succede niente.
1. Il fuso orario. Il server è spesso configurato su UTC, non sull'ora italiana. Un'attività impostata alle 3:00 parte alle 4:00 o alle 5:00 ora locale a seconda dell'ora legale. Verifica sempre il fuso del sistema prima di impostare orari che contano.
2. I percorsi relativi. Cron esegue i comandi da una posizione che potrebbe non essere quella che immagini. Uno script che funziona quando lo lanci a mano fallisce da cron perché non trova un file. Usa sempre percorsi assoluti.
3. Le variabili d'ambiente mancanti. Cron parte con un ambiente minimo: le variabili definite nel tuo profilo non ci sono. Chiavi API, stringhe di connessione, persino il percorso dell'interprete possono mancare. È la causa numero uno di "funziona da terminale ma non da cron".
4. Le esecuzioni sovrapposte. Se un'attività ogni 5 minuti impiega 8 minuti, dopo un'ora ne hai diverse in esecuzione insieme. Serve un meccanismo di blocco che impedisca l'avvio se la precedente non è finita.
5. Nessuna notifica di errore. È l'errore più grave: senza log e senza avviso, un cron job può essere fermo da mesi. Ci si accorge quando serve il backup e non c'è.
6. Far partire tutto allo scoccare dell'ora. Se tutte le attività sono a 0 * * * *, si accavallano. Distribuiscile su minuti diversi.
Come farli bene
Registra sempre l'esito. Redirigi l'output su un file di log, con data e ora:
0 3 * * * /usr/bin/python3 /percorso/assoluto/script.py >> /var/log/mio-script.log 2>&1
Il 2>&1 finale è importante: cattura anche gli errori, non solo l'output normale.
Fatti avvisare quando fallisce. Una notifica in caso di errore, o meglio ancora un sistema di controllo attivo: lo script segnala a un servizio esterno di aver finito, e se quel segnale non arriva ricevi un avviso. È l'unico modo per accorgersi di un'attività che ha smesso di partire.
Rendi lo script ripetibile senza danni. Se viene eseguito due volte per errore, non deve creare duplicati o problemi.
Provalo a mano prima, e possibilmente con lo stesso ambiente minimo che avrà da cron.
Metti un limite di tempo. Uno script bloccato che resta appeso per ore consuma risorse e blocca le esecuzioni successive.
Documenta cosa fa. Un commento sopra ogni riga del crontab: tra sei mesi non ricorderai a cosa serviva.
Un'alternativa da conoscere
Il cron è a tempo: parte a orari fissi indipendentemente da cosa succede. Per molte esigenze è la scelta giusta.
Ma se stai usando un cron per controllare periodicamente se è successo qualcosa, spesso esiste un modo migliore: il webhook, cioè farsi avvisare dall'altro sistema nel momento in cui l'evento accade. È più immediato e non spreca esecuzioni a vuoto.
La regola pratica: cron per le attività a scadenza, webhook per le reazioni a eventi.
In sintesi
Un cron job esegue un comando a orari stabiliti, con una sintassi di cinque campi — minuto, ora, giorno, mese, giorno della settimana — dove l'asterisco significa "ogni".
Si configurano su server con crontab -e, sui pannelli di hosting con un modulo, e sulle piattaforme cloud con le attività pianificate integrate.
Gli errori che li fanno fallire sono sempre gli stessi: fuso orario, percorsi relativi, variabili d'ambiente mancanti, esecuzioni sovrapposte. E il più grave di tutti è non accorgersene, perché un cron job rotto non protesta.
La regola che vale più di tutte le altre: registra sempre l'esito e fatti avvisare quando fallisce. Un'attività pianificata senza monitoraggio è un problema che aspetta il momento peggiore per manifestarsi.