Come leggere un'espressione cron
Cron è la sintassi di pianificazione usata da Linux e dalla grande maggioranza degli scheduler di job. È composta da diversi campi separati da spazi, ciascuno dei quali descrive una dimensione del tempo. La chiave per leggerla non è memorizzare la sintassi, ma capire che i campi sono uniti da «e». Il job parte solo quando tutti i campi corrispondono contemporaneamente.
Cosa sono i cinque campi
- Campo 1 — minuto: 0–59
- Campo 2 — ora: 0–23 con orologio a 24 ore, quindi le 15 si scrivono 15
- Campo 3 — giorno del mese: 1–31
- Campo 4 — mese: 1–12
- Campo 5 — giorno della settimana: 0–7, dove sia 0 sia 7 significano domenica (alcune implementazioni fanno di 1 il lunedì, quindi attenzione)
Se lo scheduler supporta la precisione al secondo (l'@Scheduled(cron=...) di Spring, Quartz), viene anteposto un campo secondi, ottenendo sei campi. Ecco perché lo stesso pattern incollato in punti diversi può «partire più spesso del previsto»: un pattern a cinque campi interpretato come sei sposta ogni campo di uno.
Le cinque notazioni
- Un valore specifico:
30significa il 30º minuto. - Un intervallo:
9-18corrisponde da 9 a 18 compresi entrambi gli estremi. - Un elenco:
1,3,5significa uno qualsiasi di quei tre valori. - Un passo:
*/5significa ogni 5º valore a partire dall'inizio;10-40/5significa ogni 5 minuti da 10 a 40. - Un jolly:
*significa «in questo campo va bene qualsiasi cosa».
Si possono mescolare, quindi 0,30 9-17 * * 1-5 significa «allo scoccare dell'ora e alla mezz'ora, tra le 9 e le 17, da lunedì a venerdì».
Analizziamo un'espressione reale
Prendiamo */5 9-18 * * 1-5 campo per campo:
- Minuto
*/5: ogni 5 minuti (0, 5, 10 … 55) - Ora
9-18: dalle 9 alle 18 - Giorno
*: qualsiasi data - Mese
*: qualsiasi mese - Giorno della settimana
1-5: da lunedì a venerdì
Messi insieme si legge: «ogni 5 minuti dalle 9:00 alle 18:55 nei giorni feriali». Aggiornare spesso i dati durante l'orario di lavoro e fermarsi dopo la chiusura è un pattern molto comune.
Le tre trappole in cui si cade più spesso
- Quando sono limitati sia «giorno del mese» sia «giorno della settimana», vale «o», non «e». È la regola più controintuitiva di cron.
0 0 13 * 5può voler dire «il 13, se è venerdì», ma in realtà significa «il 13 del mese oppure ogni venerdì» — più di dieci volte tanto. Per esprimere «e» serve un approccio diverso o un controllo dentro lo script. - Non usate
*/nper un periodo esatto attraverso il confine delle 24 ore.*/7nel campo minuti è in realtà 0, 7, 14 … 56, poi l'ora successiva riparte da 0: dopo il minuto 56 passano solo 4 minuti. Per un periodo rigoroso (esattamente ogni 7 minuti) usate il campo secondi o uno scheduler dedicato. - Non esiste un campo anno. Il cron standard non può esprimere «solo nel 2026». Limitate l'anno dentro lo script del job, oppure usate una sintassi estesa che lo supporta (Quartz sì; il crontab standard no).
In cosa differisce dai timer di systemd
Sul Linux moderno potete usare i timer di systemd invece del crontab. La sintassi differisce: il crontab è una riga, mentre systemd richiede sia un file .service sia un file .timer. I vantaggi di systemd sono un formato più leggibile come OnCalendar, la registrazione del risultato dell'ultima esecuzione e una politica di recupero per le esecuzioni mancate (Persistent=true). Per macchine che non restano accese 24 ore su 24 i timer di systemd sono più affidabili: cron semplicemente non esegue i job persi mentre la macchina era spenta.
Anche i fusi orari contano: cron usa l'ora locale del server. I container usano di norma UTC, quindi il vostro «ogni giorno alle 8» accuratamente testato in un container può diventare le 16. Verificate sempre l'impostazione del fuso orario dopo il deploy.
Come verificare un'espressione
Non a mente. Incollate l'espressione nella casella qui sopra e lo strumento elenca le prossime 10 esecuzioni. Controllare gli orari è la verifica più rapida che esista, e mette in luce a colpo d'occhio trappole come l'OR tra giorno e giorno della settimana: se scrivete 0 0 13 * 5, gli orari elencati includeranno sia ogni 13 del mese sia ogni venerdì, e il problema sarà subito evidente.
L'analisi avviene interamente nel browser, senza bisogno di accesso alla rete.
Domande frequenti
Che ora è 0 6 * * *?
Le 6 di ogni giorno. Il primo campo 0 significa minuto zero, il secondo campo 6 significa le 6, e gli altri tre sono jolly senza restrizioni. È uno dei pattern più comuni in assoluto.
Sono supportate le macro in stile @daily?
Il crontab standard supporta una serie di macro: @daily (mezzanotte di ogni giorno), @hourly, @weekly, @monthly, @yearly, @reboot (una volta dopo l'avvio). Questo strumento si concentra sulle espressioni numeriche standard; sostituite voi la macro: @daily è 0 0 * * *.
Perché 7 funziona per il giorno della settimana?
Perché sia 0 sia 7 sono definiti come domenica, quindi va bene l'uno o l'altro. Per indicare lunedì, però, usate 1: non scrivete 8. Alcuni sistemi definiscono il giorno della settimana da 1 a 7 con 1 come domenica, quindi verificate sempre quando cambiate piattaforma.
Gli orari previsti non corrispondono a quando parte davvero?
Controllate prima il fuso orario. Container e funzioni cloud usano per lo più UTC, che è 8 ore avanti rispetto all'ora di Pechino. Poi verificate se lo scheduler si aspetta cinque o sei campi: aggiungerne o ometterne uno sposta l'intera stringa.
Può calcolare tutte le esecuzioni del prossimo anno?
Lo strumento ne elenca 10 per impostazione predefinita, più che sufficienti a validare la logica. Per fare i totali (per esempio per valutare il carico dei job) usate gli strumenti di analisi dello scheduler stesso o calcolatelo lato server.