Analizza un’espressione cron _

Che cos’è un’espressione cron?

Un’espressione cron è una stringa di pianificazione compatta che dice a uno scheduler esattamente quando eseguire un task. Il formato nacque nel 1975 nel demone cron di Unix V7 e non è praticamente cambiato da allora — la stessa grammatica a cinque campi compare oggi nei CronJob Kubernetes, in AWS EventBridge, nei workflow di GitHub Actions, in Google Cloud Scheduler, in GitLab CI, nelle pipeline Jenkins e nel binario crontab ancora distribuito con ogni distribuzione Linux. La grammatica racchiude molto significato in tredici o più caratteri, ecco perché un parser che la converte in italiano è la differenza tra un deploy sicuro e un rollback alle 3 di notte.

Come funziona un’espressione cron?

Un’espressione cron standard ha cinque campi separati da spazio che insieme definiscono una pianificazione ripetuta. Il motore confronta l’orologio corrente con l’espressione ogni minuto ed esegue il job quando tutti e cinque i campi corrispondono. I campi, da sinistra a destra:

1. Minuto (0–59). Quale minuto dell’ora viene eseguito il job. 0 significa all’ora esatta, 30 significa e mezza, */5 significa ogni cinque minuti (00, 05, 10, …), e 15,45 significa al quarto d’ora e alle meno un quarto.
2. Ora (0–23). Quale ora del giorno nel formato 24 ore. 0 è mezzanotte, 9 sono le 9:00, 17 sono le 17:00. Intervalli (9-17 per l’orario lavorativo) e valori di passo (*/2 per ogni due ore) funzionano come per i minuti.
3. Giorno del mese (1–31). Quale giorno del calendario eseguire. 1 indica il primo del mese, * indica ogni giorno, 1,15 indica il primo e il quindici. Attenzione a 31 — salta silenziosamente i mesi che non hanno 31 giorni.
4. Mese (1–12 o JAN–DEC). Quali mesi eseguire. * indica ogni mese, 1,7 indica gennaio e luglio, 1-3 indica solo il primo trimestre. I nomi dei mesi a tre lettere non sono case-sensitive nella maggior parte delle implementazioni.
5. Giorno della settimana (0–7, dove sia 0 che 7 indicano domenica). Restringe l’esecuzione a giorni della settimana specifici. 1-5 è da lunedì a venerdì, 0,6 è il weekend, MON-FRI funziona nella maggior parte dei parser. Quando sia il giorno del mese che il giorno della settimana sono impostati su valori specifici, il cron classico scatta a qualsiasi corrispondenza (OR logico) — il che sorprende ogni volta.

Perché usare un parser di espressioni cron?

• Individua il malinteso silenzioso prima del deploy. L’espressione `0 2 */3 * *` scatta alle 2:00 ogni tre giorni, non ogni tre minuti — incollala qui e lo vedrai in italiano prima che vada in produzione.
• La maggior parte degli scheduler cloud gira in UTC per impostazione predefinita. Visualizzare le prossime dieci esecuzioni nel tuo fuso locale evidenzia lo scarto di un’ora dovuto all’ora legale prima che qualcuno venga svegliato alle 3 di notte.
• Scorciatoie come `@daily`, `@weekly` e `@monthly` sono comode ma ambigue. Il parser mostra il formato sottostante a cinque campi in modo che tu sappia esattamente cosa è stato pianificato.
• Il costruttore campo per campo ti permette di comporre una pianificazione una colonna alla volta e vedere la descrizione in linguaggio naturale aggiornarsi in tempo reale, molto più veloce che rileggere la man page di cron per la decima volta.

Dove vengono usate le espressioni cron?

La sintassi cron compare ovunque un job debba ripetersi a orologio. Tre delle superfici più comuni, con la criticità per cui ognuna è nota:

• Pianificazioni di backup. La classica voce `crontab -e` che scarica un database su S3 alle 2:00 di notte, o ruota un archivio `pg_dump` il primo di ogni mese. Una riga come `0 2 * * * /usr/local/bin/backup.sh` è stata distribuita su più server Linux di qualsiasi altra riga cron nella storia. Imposta correttamente minuto e ora, reindirizza stderr in un posto durevole e hai sostituito una checklist manuale con uno script fire-and-forget.
• Trigger `schedule` di GitHub Actions. La chiave `on.schedule.cron` in `.github/workflows/*.yml` accetta il cron standard a cinque campi, ma il job gira sempre in UTC e GitHub salterà silenziosamente un’esecuzione se la coda dei runner è occupata. Pattern comune: `cron: '0 9 * * 1-5'` per inviare un digest dal lunedì al venerdì alle 9:00 UTC. Visualizzalo qui nel tuo fuso locale prima di promettere un digest alle 9:00 di Londra che in realtà arriva alle 10:00 nell’ora legale.
• AWS EventBridge Scheduler. Le espressioni cron EventBridge accettano un sesto campo per l’anno e richiedono `?` invece di `*` nel campo del giorno del mese o del giorno della settimana — `cron(0 9 ? * MON-FRI *)` è la traduzione EventBridge del classico cron standard per i giorni lavorativi alle 9:00. Utilizzato per invocazioni Lambda pianificate, esecuzioni di task ECS e avvii di macchine a stati Step Function; il disallineamento con la sintassi cron classica è la fonte numero uno di errori `ValidationException` nei deploy CloudFormation.

Come appare una vera espressione cron?

Prendi 0 9 * * 1-5 — scatta alle 9:00 ogni giorno feriale. Leggendo i campi da sinistra a destra: 0 è il minuto zero dell’ora, 9 sono le 9:00 nel formato 24 ore, * sul giorno del mese significa ogni giorno del calendario, * sul mese significa ogni mese, e 1-5 sul giorno della settimana restringe l’esecuzione da lunedì a venerdì (dove 1 = lunedì nella numerazione cron standard). Incollala nell’input sopra e il parser conferma Alle 09:00, dal lunedì al venerdì con le prossime dieci date nel fuso IANA che selezioni. La stessa intenzione nella sintassi AWS EventBridge è cron(0 9 ? * MON-FRI *) — nota il campo dell’anno alla fine e il ? dove il cron standard userebbe *. La stessa intenzione come espressione Quartz (sei campi con i secondi iniziali) è 0 0 9 ? * MON-FRI. Tre piattaforme diverse, tre forme di superficie diverse, una sola pianificazione sottostante.

Le espressioni cron sono impietose in un unico modo: un errore di battitura produce una pianificazione sintatticamente valida che scatta all’ora sbagliata, senza nessun errore da intercettare in code review. Leggere `0 0 1 * *` e sapere che gira a mezzanotte del primo di ogni mese, non il primo gennaio, richiede pratica. Il parser qui sopra trasforma quella pratica in un controllo di dieci secondi — incolla l’espressione, leggi l’italiano, scorri le prossime dieci esecuzioni nel tuo fuso e fai il commit sapendo che la riga cron fa davvero quello che dice il messaggio di commit.

Qual è la differenza tra cron a 5 e 6 campi?

Il cron a cinque campi è la grammatica Unix classica con risoluzione al minuto. Il cron a sei campi aggiunge una colonna iniziale per i secondi, per la pianificazione sub-minuto — usato da Quartz e dall’annotazione @Scheduled di Spring. AWS EventBridge usa anche sei campi, ma il campo extra è un anno finale, non i secondi.

Cosa significano @hourly, @daily e @weekly?

Nickname di Vixie-cron introdotti nel 1987. @hourly = 0 * * * *, @daily = 0 0 * * *, @weekly = 0 0 * * 0, @monthly = 0 0 1 * *, @yearly = 0 0 1 1 *. @reboot scatta una volta all’avvio. GitHub Actions ed EventBridge non accettano questi alias.

In cron, la domenica è il giorno 0 o il 7?

Entrambi, nel cron Vixie classico — 0 e 7 sono entrambi accettati in modo che intervalli come 5-7 si leggano naturalmente come venerdì-domenica. Lunedì è sempre 1, sabato è sempre 6. Quartz e AWS EventBridge usano una convenzione diversa: 1-7 con domenica come 1. Controlla la documentazione della piattaforma prima di fare supposizioni.

Come gestisce cron l’ora legale?

Dipende dal fuso orario del motore. In UTC (il default su EventBridge, Kubernetes e GitHub Actions) l’ora legale non esiste. In un fuso locale con ora legale, il cron Vixie classico salta i job durante il passaggio all’ora legale e li esegue due volte durante il ritorno; i timer systemd scattano esattamente una volta.