Crontab Guru

Scheda di riferimento dei campi

 ┌───────────── minuto (0-59)
 │ ┌─────────── ora (0-23)
 │ │ ┌───────── giorno del mese (1-31)
 │ │ │ ┌─────── mese (1-12 o GEN-DIC)
 │ │ │ │ ┌───── giorno della settimana (0-6 o DOM-SAB; Dom = 0 o 7)
 │ │ │ │ │
 * * * * *

Operatori nelle espressioni cron

L’ordine di lettura è importante

0 */2 * * 1-5 si legge da sinistra a destra come: minuto 0, ogni 2 ore, qualsiasi giorno del mese, qualsiasi mese, da lunedì a venerdì. Per abitudine, a volte si leggono i campi da destra a sinistra e ci si confonde; inizia sempre dal minuto.

La trappola dei “ogni X minuti”

*/10 * * * * si attiva ai minuti 0, 10, 20, 30, 40, 50, non “ogni 10 minuti da quando è stato creato il lavoro.” I passi cron misurano sempre dall’inizio dell’intervallo del campo. Se distribuisci un lavoro alle 12:03, la prima esecuzione è alle 12:10, non alle 12:13.

Per i lavori che hanno davvero bisogno di “N minuti dopo l’ultima esecuzione,” usa un pianificatore con un timer persistente (timer systemd con OnUnitActiveSec, o pianificazione a livello di applicazione con un timestamp dell’ultima esecuzione memorizzato).

Insidie di cron che conviene conoscere

• Giorno del mese + giorno della settimana entrambi impostati: la maggior parte delle implementazioni cron lo tratta come comportamento OR, probabilmente non quello che vuoi.
• Passo di 0: */0 non è valido.
• Intervallo che si avvolge: 22-2 per le ore non funziona nel cron classico; usa 22-23,0-2.
• 30 febbraio: un programma come 0 0 30 2 * non si attiva mai.
• Ambiguità DST: i lavori pianificati tra le 2 e le 3 di notte possono attivarsi due volte o zero volte nei giorni di cambio ora.

Cron vs pianificatori moderni

Unix cron è ancora ovunque, ma per qualsiasi cosa critica probabilmente vorrai:

• timer systemd: catturare esecuzioni mancate, supportare offset casuali, leggere dai file di unità.
• Kubernetes CronJob: dichiarativo, retry, consapevole del fuso orario in 1.25+.
• Airflow / Prefect / Dagster: per lavori con dipendenze, retry, backfill e osservabilità.
• Pianificazione di GitHub Actions: cron a 5 campi, solo UTC, intervallo minimo di 5 minuti, consegna best-effort.

Il cron in sé è un ottimo formato, ma un cattivo pianificatore per lavori che non devono essere persi.