Cron usa il fuso orario del server o UTC?

Il cron Unix classico usa il fuso orario locale del sistema, che corrisponde a ciò a cui punta /etc/localtime. Molti scheduler cloud (AWS EventBridge, GCP Cloud Scheduler) usano UTC per impostazione predefinita e consentono di optare per una zona IANA specifica per regola. Stampare sempre il fuso orario risolto nella prima riga di log del lavoro — elimina un’intera categoria di bug post-DST.

Perché il mio lavoro è stato eseguito due volte la mattina in cui è terminato l’ora legale?

Quando gli orologi tornano indietro dalle 02:00 alle 01:00, l’ora tra le 01:00 e le 02:00 si verifica due volte sull’orologio locale. Un lavoro pianificato alle 01:30 in una zona con ora legale viene eseguito entrambe le volte, a meno che l’implementazione cron non esegua esplicitamente la deduplicazione.

Qual è l’intervallo minimo supportato da cron?

Un minuto. Il primo campo è i minuti; non esiste un campo secondi nel crontab POSIX. Se è necessaria una pianificazione sub-minuto, usare un processo a lunga esecuzione con il proprio sleep loop, timer systemd con OnUnitActiveSec o uno scheduler dedicato come Quartz che supporta un campo secondi.

@hourly, @daily, @reboot sono portabili?

Le stringhe abbreviate (@yearly, @monthly, @weekly, @daily, @hourly) sono supportate da Vixie cron, cronie e dalla maggior parte dei derivati moderni, quindi sono sicure su Linux e macOS. @reboot è ampiamente supportato ma la sua semantica differisce — alcune implementazioni vengono eseguite una volta al prossimo avvio, altre ad ogni avvio.

Perché */7 a volte salta l’ultimo intervallo?

L’operatore di passo divide l’intero intervallo consentito, non l’orario di inizio. Per i minuti (0-59), */7 si attiva a 0, 7, 14, 21, 28, 35, 42, 49, 56 — poi il minuto successivo valido è 0 dell’ora successiva. Il divario tra 56 e 60 è solo di quattro minuti, non sette.

Dovrei usare cron nel 2026 o i timer systemd?

Su un singolo host Linux senza orchestratore, i timer systemd sono di solito un’impostazione predefinita migliore: log strutturato tramite journalctl, ordinamento delle dipendenze, randomizzazione più facile con RandomizedDelaySec e limiti di risorse a livello di unità. Cron vince quando è necessaria la portabilità su sistemi non systemd o quando l’intera automazione è una riga in un crontab.

Guide

Tutorial sulle espressioni cron: come leggere e scrivere le pianificazioni crontab

Cinque campi, sei caratteri speciali e un bug storico che decide se il lavoro viene eseguito una o due volte.

By Buğra SözeriPublished May 31, 2026

Cron ha quarant’anni ed è ancora lo scheduler predefinito su quasi tutti i sistemi Unix distribuiti quest’anno. La sintassi occupa una riga, il che è la ragione principale per cui è sopravvissuta — ed è anche il motivo per cui viene sistematicamente letta male. Questa guida descrive i cinque campi, ogni carattere speciale, la particolarità giorno-del-mese vs giorno-della-settimana e una piccola libreria di espressioni da copiare direttamente in un crontab.

L’anatomia a cinque campi

Un’espressione cron POSIX ha cinque campi separati da spazi, in questo ordine:

# ┌──────────── minuto        (0 - 59)
# │ ┌────────── ora           (0 - 23)
# │ │ ┌──────── giorno mese   (1 - 31)
# │ │ │ ┌────── mese          (1 - 12)  o GEN-DIC
# │ │ │ │ ┌──── giorno sett.  (0 - 6)   o DOM-SAB, dove 0 e 7 sono domenica
# │ │ │ │ │
  *  *  *  *  *   comando-da-eseguire

Ogni campo deve essere presente. Non ci sono valori predefiniti e nessuna scorciatoia posizionale. Un campo con *significa “ogni valore valido in questo intervallo,” non “salta.” Questa distinzione diventa importante non appena si inizia a combinare i campi.

Perché due campi per il giorno?

Cron consente di dire “ogni lunedì” e “il primo del mese” sulla stessa riga, il che sarebbe ambiguo se entrambi i campi dovessero essere d’accordo. La risoluzione storica è la semantica ORquando entrambi i campi sono limitati: il lavoro si attiva quando il giorno-del-mese o il giorno-della-settimana corrisponde.

Caratteri speciali

* — ogni valore

Corrisponde a ogni valore valido nel campo. * * * * * significa ogni minuto di ogni ora di ogni giorno.

, — elenco

La virgola separa valori discreti. 0,15,30,45 * * * * si attiva all’ora esatta, al quarto d’ora, alla mezzora e ai tre quarti di ogni ora.

- — intervallo

Il trattino definisce un intervallo inclusivo. 0 9-17 * * 1-5 si attiva all’ora esatta da 09:00 a 17:00 incluse, dal lunedì al venerdì.

/ — passo

La barra applica un passo a un intervallo. */5nel campo minuti è l’abbreviazione di 0-59/5 — ogni cinque minuti a partire dal minuto 0.

? — nessun valore specifico (solo Quartz)

Il carattere ? nonè POSIX. Compare nel cron in stile Quartz (e AWS EventBridge) e significa “nessun valore specifico.”

Valori con nome

I mesi accettano GEN FEB MAR APR MAG GIU LUG AGO SET OTT NOV DIC, i giorni della settimana accettano DOM LUN MAR MER GIO VEN SAB. In caso di dubbio, usare la forma numerica.

Ricette

Il modo più veloce per interiorizzare cron è leggere qualche decina di espressioni affiancate all’inglese semplice. Incollare una di queste nel nostro generatore di espressioni cron per vedere i prossimi dieci orari di attivazione nel proprio fuso orario locale.

Ogni N minuti

* * * * * — ogni minuto
*/5 * * * * — ogni cinque minuti, al minuto 0, 5, 10…
*/15 * * * * — ogni quarto d’ora
0,30 * * * * — all’ora e alla mezzora

Varianti orarie

0 * * * * — ogni ora in punto
0 */2 * * * — ogni due ore a partire dalle 00:00
0 9-17 * * * — in punto, dalle 09:00 alle 17:00 incluse

Varianti giornaliere

0 0 * * * — mezzanotte ogni giorno
30 3 * * * — 03:30 ogni giorno — la classica finestra di backup
0 9 * * 1-5 — 09:00 nei giorni feriali
0 18 * * 5 — 18:00 solo il venerdì

La particolarità OR di giorno-del-mese / giorno-della-settimana

La specifica è inequivocabile: se entrambi il campo giorno-del-mese e il campo giorno-della-settimana sono limitati (cioè non *), il lavoro si attiva quando una qualsiasi delle condizioni corrisponde, non entrambe.

Considerare 0 0 1 * 1. Una lettura naturale è “mezzanotte il primo del mese, ma solo se è lunedì.” Il comportamento effettivo è “mezzanotte il primo di ogni meseomezzanotte ogni lunedì.”

Errori comuni

Trattare la barra come un vero periodo

*/Ndivide l’intervallo del campo, quindi il periodo tra l’ultimo attivazione di un’ora e il primo attivazione dell’ora successiva è più breve di N. Se è necessario uno spaziamento rigoroso di N minuti, cron è lo strumento sbagliato.

Assumere il PATH del lavoro

Cron gira con un ambiente minimale. PATH è tipicamente/usr/bin:/bin e le alias della shell non esistono. Usare percorsi assoluti a ogni binario o impostare PATH=all’inizio del crontab.

Scheda di riferimento rapido

Espressione	Significato
`* * * * *`	ogni minuto
`/5 * * *`	ogni 5 minuti
`0 * * * *`	all’inizio di ogni ora
`0 9-17 * * 1-5`	ogni ora, 9-17, feriali
`0 0 * * *`	mezzanotte ogni giorno
`30 3 * * 0`	03:30 ogni domenica
`0 0 1 * *`	mezzanotte il 1° di ogni mese
`0 0 1 1 *`	mezzanotte il 1° gennaio
`@reboot`	una volta all’avvio dello scheduler

Il modo più economico per evitare un avviso alle 3 del mattino è incollare l’espressione in un parser prima di salvare il crontab. Il nostro generatore di espressioni cron stampa i prossimi dieci orari di attivazione nel fuso orario locale e in UTC, oltre a una descrizione in linguaggio semplice che individua immediatamente la particolarità giorno-del-mese / giorno-della-settimana.

Frequently asked questions

Cron usa il fuso orario del server o UTC?: Il cron Unix classico usa il fuso orario locale del sistema, che corrisponde a ciò a cui punta /etc/localtime. Molti scheduler cloud (AWS EventBridge, GCP Cloud Scheduler) usano UTC per impostazione predefinita e consentono di optare per una zona IANA specifica per regola. Stampare sempre il fuso orario risolto nella prima riga di log del lavoro — elimina un’intera categoria di bug post-DST.
Perché il mio lavoro è stato eseguito due volte la mattina in cui è terminato l’ora legale?: Quando gli orologi tornano indietro dalle 02:00 alle 01:00, l’ora tra le 01:00 e le 02:00 si verifica due volte sull’orologio locale. Un lavoro pianificato alle 01:30 in una zona con ora legale viene eseguito entrambe le volte, a meno che l’implementazione cron non esegua esplicitamente la deduplicazione.
Qual è l’intervallo minimo supportato da cron?: Un minuto. Il primo campo è i minuti; non esiste un campo secondi nel crontab POSIX. Se è necessaria una pianificazione sub-minuto, usare un processo a lunga esecuzione con il proprio sleep loop, timer systemd con OnUnitActiveSec o uno scheduler dedicato come Quartz che supporta un campo secondi.
@hourly, @daily, @reboot sono portabili?: Le stringhe abbreviate (@yearly, @monthly, @weekly, @daily, @hourly) sono supportate da Vixie cron, cronie e dalla maggior parte dei derivati moderni, quindi sono sicure su Linux e macOS. @reboot è ampiamente supportato ma la sua semantica differisce — alcune implementazioni vengono eseguite una volta al prossimo avvio, altre ad ogni avvio.
Perché */7 a volte salta l’ultimo intervallo?: L’operatore di passo divide l’intero intervallo consentito, non l’orario di inizio. Per i minuti (0-59), */7 si attiva a 0, 7, 14, 21, 28, 35, 42, 49, 56 — poi il minuto successivo valido è 0 dell’ora successiva. Il divario tra 56 e 60 è solo di quattro minuti, non sette.
Dovrei usare cron nel 2026 o i timer systemd?: Su un singolo host Linux senza orchestratore, i timer systemd sono di solito un’impostazione predefinita migliore: log strutturato tramite journalctl, ordinamento delle dipendenze, randomizzazione più facile con RandomizedDelaySec e limiti di risorse a livello di unità. Cron vince quando è necessaria la portabilità su sistemi non systemd o quando l’intera automazione è una riga in un crontab.

Published May 31, 2026