Cron job: 6 errori che fanno partire le automazioni all'ora sbagliata

Hai impostato un cron job alle 09:00, ma parte alle 10:00? Oppure un’automazione smette di funzionare quando cambia l’ora legale? Non è sempre colpa della sintassi: spesso l’espressione è valida, ma il server la interpreta con un fuso, un calendario o regole differenti.

Questi sono sei errori frequenti, con esempi da adattare al proprio ambiente e due strumenti gratuiti per verificare la pianificazione prima di attivarla. Nessun account richiesto.

Provalo subito: apri il generatore e validatore Cron Sikelia Tools, descrivi la pianificazione in italiano, seleziona l’ambiente, verifica l’espressione a cinque campi e controlla le prossime esecuzioni. La preview non esegue alcun job.

Schermata reale del generatore Cron Sikelia Tools: Ogni giorno alle 15 è interpretato come 0 15 * * * con indicatore di validità
Screenshot reale del validatore Cron. Clicca sull’immagine per aprire lo strumento.

1. Contare male i campi di Cron

Il formato classico a cinque campi segue l’ordine minuto ora giorno-del-mese mese giorno-della-settimana. Per esempio 0 9 * * 1-5 indica comunemente le 09:00 dal lunedì al venerdì. Ma alcuni scheduler usano anche i secondi o dialetti diversi. Una stringa valida non è automaticamente portabile da un sistema all’altro.

Soluzione: identifica prima il runtime (Linux/POSIX, piattaforma cloud, orchestratore) e verifica il numero di campi e le regole nella documentazione ufficiale del servizio.

2. Dimenticare che 09:00 UTC non significa 09:00 italiane

La stringa 0 9 * * * non specifica il fuso. Se il server la interpreta in UTC, in Italia l’esecuzione corrisponde tipicamente alle 10:00 in inverno o alle 11:00 in estate, non alle nove locali. Quando il servizio lo permette, configura esplicitamente Europe/Rome; altrimenti documenta e gestisci la conversione.

Scrivere “ogni giorno alle nove” senza dire dove è una specifica incompleta. Verifica anche che il preview del tool e il runtime remoto usino lo stesso fuso.

3. Ignorare l’ora legale e i minuti che non esistono

Nei passaggi tra ora solare e ora legale, alcune ore locali possono saltare o ripetersi. Un job previsto alle 02:30 può essere saltato o valutato diversamente dallo scheduler; la sintassi Cron, da sola, non garantisce esattamente un’esecuzione.

Per pagamenti, messaggi e aggiornamenti di database usa idempotenza, monitoraggio e test intorno alle transizioni stagionali. L’Orologio mondiale Sikelia Tools aiuta a confrontare i fusi correnti; per le date future resta necessario verificare le regole dello scheduler.

Screenshot reale dell’Orologio mondiale Sikelia Tools con UTC, Londra, Parigi, New York, Tokyo e Roma
L’Orologio mondiale mostra le differenze attuali fra UTC e le principali città, anche su smartphone.

4. Confondere giorno del mese e giorno della settimana

La combinazione di questi campi cambia da un dialetto all’altro. Espressioni come 0 9 1 * 1 possono avere significati diversi a seconda dell’implementazione. Non interpretare “a intuito” l’uso simultaneo dei due campi.

Se il requisito è “il primo lunedì del mese”, valuta una regola supportata dal sistema oppure una verifica nel codice applicativo, e testa le occorrenze dei prossimi mesi.

5. Tradurre una richiesta vaga in un’espressione troppo precisa

“Ogni tanto la sera” non definisce una pianificazione. “Ogni giorno alle 18:30, ora di Roma, inclusi i weekend” sì. Il convertitore da descrizione a Cron interpreta le formulazioni che supporta e mostra il risultato: rileggilo prima di incollarlo in produzione.

6. Credere che il validatore attivi e controlli il job

Un validatore mostra quando dovrebbe partire la pianificazione, non se il server è online o ha permessi corretti. Timeout, retry, code sovraccariche e problemi di rete restano possibili. Una vera verifica richiede log, metriche e almeno una prova di esecuzione nell’ambiente di destinazione.

Tre esempi pratici

Espressione a 5 campiSignificato abituale
0 9 * * 1-509:00 da lunedì a venerdì
30 18 * * *18:30 ogni giorno
0 */2 * * *Ogni due ore, minuto 00

In tutti e tre gli esempi il fuso, il dialetto e le limitazioni del servizio vanno verificati separatamente.

Checklist da salvare prima del deploy

  1. Scrivi il requisito completo: ora, fuso, giorni e calendario.
  2. Controlla numero di campi e dialetto del runtime.
  3. Confronta almeno cinque esecuzioni future e, se rilevante, quelle vicine al cambio d’ora.
  4. Prepara log, alert, retry e idempotenza per gli effetti esterni.
  5. Verifica almeno un’esecuzione reale con un’azione non distruttiva.

Sikelia Tools si installa sul telefono come una vera app

Non devi cercare un pacchetto in uno store. Apri Sikelia Tools nel browser e, se il dispositivo offre l’opzione, aggiungilo alla schermata Home.

  • Android / Chrome: menu → Installa app oppure Aggiungi a schermata Home.
  • iPhone / Safari: Condividi → Aggiungi alla schermata Home.

L’icona apre un’interfaccia adattata al telefono. Le novità arrivano attraverso il sito, senza scaricare manualmente nuove versioni dagli store; per aggiornarsi è necessario tornare online e, in certi casi, riaprire l’app. Le disponibilità offline dipendono dai contenuti già salvati nel dispositivo.

Generatore Cron Sikelia Tools su smartphone, interfaccia mobile con pulsanti della navigazione inferiore
Il generatore Cron visto su smartphone. La schermata può variare in base al dispositivo.

In conclusione

Per far partire un’automazione all’ora giusta devono combaciare espressione, fuso, scheduler e comportamento in caso di errore. Parti dal validatore Cron, usa l’Orologio mondiale per un confronto e conferma tutto nei log del servizio reale.

Commenti

Post popolari in questo blog

Timer online o cronometro online? Differenze e 6 esempi pratici

Firefox migliora PDF e schede Android: le novità già disponibili e quelle ancora in arrivo