Generatore Crontab e Costruttore di Espressioni Cron

Cos'è un'espressione cron?

# Linux crontab entry — runs every 15 minutes
*/15 * * * *  /usr/local/bin/poll-api.sh

# Kubernetes CronJob — weekdays at 9:00 AM UTC
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-report
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "UTC"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: report
              image: report-runner:1.0
          restartPolicy: OnFailure

# GitHub Actions workflow — hourly
on:
  schedule:
    - cron: '0 * * * *'

# AWS EventBridge — first of each month
ScheduleExpression: cron(0 0 1 * ? *)
# (Note: AWS uses the Quartz 6-field form with '?' for day-of-week)

Caratteristiche principali

Varianti di cron e scheduler

Esempi di espressioni cron

*/15 * * * *

0 9 * * 1-5

0 0 1 * *

*/5 9-17 * * 1-5

0 0 1 JAN,APR,JUL,OCT *

0 0 1 * 5

30 2 * * *

@daily

Come costruire un'espressione cron

1. 1

   Scrivi o incolla un'espressione cron

   Inserisci un'espressione cron a cinque campi nel campo qui sopra (es. `*/15 * * * *`). Lo strumento analizza e valida mentre digiti — spunta verde se valida, errore rosso con il nome del campo se non valida. Sono accettate anche le macro come `@daily`, `@hourly`, ecc.

2. 2

   Oppure modifica i cinque campi

   Non memorizzare l'ordine dei campi — modifica Minuto, Ora, Giorno del mese, Mese o Giorno della settimana singolarmente tramite gli input etichettati. L'espressione completa in alto si aggiorna automaticamente. Usa `*` per le wildcard, `*/N` per i passi, `a-b` per gli intervalli e `1,3,5` per le liste.

3. 3

   Scegli un preset per partire

   Tocca un qualunque chip preset (Ogni 15 minuti, Giorni feriali alle 9, ecc.) per caricare una pianificazione comune, poi adatta i campi alle tue esigenze. Undici preset coprono i pattern che userai davvero in produzione.

4. 4

   Verifica l'anteprima delle prossime esecuzioni

   Guarda le cinque date e ore di esecuzione imminenti — passa tra Locale e UTC per confermare che la pianificazione parta quando intendi. È il modo più affidabile per cogliere il trabocchetto OR POSIX del giorno del mese/giorno della settimana prima che ti morda in produzione.

5. 5

   Copia e incolla nel tuo scheduler

   Clicca su Copia per prendere l'espressione. Incolla nel tuo crontab, in un timer systemd, nel `cron:` di GitHub Actions, in AWS EventBridge, nello `schedule` di un Kubernetes CronJob o in qualunque scheduler compatibile con cron. Non dimenticare di verificare il fuso orario dello scheduler target — vedi la sezione Best practice qui sotto.

Errori comuni di cron

# Intenzione: "primo venerdì del mese"
0 0 1-7 * 5
# In realtà: parte nei giorni 1-7 del mese O ogni venerdì — entrambe le condizioni

# Usa un wrapper per vera semantica AND
0 0 * * 5  [ $(date +\%d) -le 7 ] && /tuo-script
# OPPURE elimina una condizione e accetta la pianificazione più ampia

# Scritto da uno sviluppatore US East, deployato su server UTC
0 9 * * *  /tuo-report.sh
# Parte alle 9 UTC = 4 del mattino US East — non quello che intendeva lo sviluppatore

# Fissa il fuso orario, oppure scrivi in UTC esplicitamente
CRON_TZ=America/New_York
0 9 * * *  /tuo-report.sh

# Intenzione: ogni 15 minuti
15 * * * *
# In realtà: una volta all'ora, al minuto 15 (4 esecuzioni/ora in meno dell'intenzione)

# Corretto
*/15 * * * *
# Ogni 15 minuti: minuto 0, 15, 30, 45 di ogni ora

# Quartz a 6 campi copiato in crontab Linux
0 0 9 * * 1-5
# Linux legge: minuto=0, ora=0, dom=9, mese=*, dow=1-5
# = mezzanotte nei giorni 9 nei mesi che corrispondono ai giorni feriali — caos

# POSIX a 5 campi, elimina i secondi
0 9 * * 1-5
# = giorni feriali alle 9:00

# 30 o 31 febbraio — non parte mai
0 0 30 2 *
0 0 31 2 *
# Si interpreta ma nessuna pianificazione parte mai

# Usa il pattern 'ultimo giorno feriale di febbraio' tramite script
0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /tuo-script

# Quartz: 'ultimo venerdì del mese' — non valido in POSIX
0 0 ? * 6L *

# Approccio POSIX con script wrapper per ultimo-venerdì
0 0 25-31 * 5  /tuo-script
# Parte di venerdì tra il 25 e il 31 di qualunque mese

Casi d'uso comuni

Job di crontab Linux

Costruisci e verifica le voci per `/etc/crontab`, `/etc/cron.d/*` o i file `crontab -e` per utente. Usa l'anteprima delle prossime esecuzioni per confermare che la pianificazione cada all'orario giusto nel fuso orario configurato del tuo server prima di salvare.

Pianificazioni di Kubernetes CronJob

Genera il campo `spec.schedule` per un CronJob Kubernetes. Kubernetes 1.27+ supporta anche `spec.timeZone` — usa il toggle UTC per progettare la pianificazione in UTC, poi imposta esplicitamente `timeZone` per evitare l'ora locale del worker node.

Workflow pianificati di GitHub Actions

Costruisci la voce `cron:` sotto `on.schedule`. GitHub Actions gira sempre in UTC — passa l'anteprima a UTC per confermare la pianificazione. Evita intervalli inferiori a 15 minuti; lo scheduler di GitHub salta i job a intervalli brevi sotto carico.

Regole di AWS EventBridge

Componi l'espressione cron per una regola pianificata di EventBridge. Nota: AWS usa la sintassi Quartz a sei campi con `?` per il giorno della settimana — questo strumento emette POSIX a cinque campi, che dovrai convertire anteponendo i secondi (`0`) e sostituendo il `*` in uno dei due campi giorno con `?`.

Pipeline pianificate di GitLab CI

Verifica l'espressione cron per una pipeline CI pianificata in GitLab. GitLab usa la sintassi POSIX a cinque campi — quella che emette questo strumento — e un date picker nell'interfaccia, ma la forma cron ti dà controllo più fine per intervalli non standard.

Cron Triggers di Cloudflare Workers

Costruisci la voce `[triggers.crons]` in `wrangler.toml`. Cloudflare usa la sintassi POSIX a cinque campi. L'intervallo minimo è di un minuto; il worker gira in UTC. Usa l'anteprima per verificare che il trigger parta entro la finestra prevista.

Pianificazioni node-cron in Node.js

Costruisci espressioni per la libreria `node-cron`, che supporta sia POSIX a cinque campi sia un campo secondi iniziale opzionale. Resta sui cinque campi a meno che ti serva precisione sub-minuto — le espressioni a sei campi non sono portabili al crontab Linux.

Code review e documentazione

Incolla un'espressione cron da una PR o da un runbook per vedere subito cosa fa — niente più indovinelli su `30 7 * * 1-5` o consultazioni di schede di riferimento. La descrizione in linguaggio naturale è ottima anche per commenti inline e file README.

Riferimento sintassi cron

Ordine dei campi: M H D M W

Minuto (0-59), Ora (0-23), Giorno del mese (1-31), Mese (1-12), Giorno della settimana (0-6, 7 = anche domenica). Il campo del giorno della settimana accetta sia token numerici (0-6) sia nominati (SUN-SAT, non sensibili al maiuscolo/minuscolo).

Operatori

`*` = qualsiasi valore; `,` = separatore di lista (`1,3,5`); `-` = intervallo (`1-5`); `/` = passo (`*/15`, `5/10`); nomi: JAN-DEC per il mese, SUN-SAT per il giorno della settimana (non sensibili al maiuscolo/minuscolo).

Macro (alias)

`@yearly` = `0 0 1 1 *`; `@annually` = `0 0 1 1 *`; `@monthly` = `0 0 1 * *`; `@weekly` = `0 0 * * 0`; `@daily` = `0 0 * * *`; `@midnight` = `0 0 * * *`; `@hourly` = `0 * * * *`. `@reboot` è una non-pianificazione speciale (parte solo al boot) e viene rifiutata con un errore esplicativo.

Semantica dei giorni POSIX (regola OR)

Quando SIA il giorno del mese SIA il giorno della settimana sono ristretti (nessuno dei due è `*`), la pianificazione viene eseguita se UNO O L'ALTRO corrisponde — semantica OR. Quando solo uno è ristretto, decide quello. Quando entrambi sono `*`, ogni giorno corrisponde. Questa regola OR si applica a vixie cron, BSD cron e alla maggior parte delle implementazioni POSIX; Quartz usa `?` per disambiguare AND vs OR.

Modalità a sei campi (Quartz-lite)

Se il tuo input ha sei token separati da spazi, lo strumento tratta il primo come campo secondi (0-59). Utile per Quartz, Spring `@Scheduled(cron=...)` e node-cron. NON portabile al crontab Linux o agli scheduler POSIX — tratterebbero i tuoi secondi come minuti e sposterebbero tutto di una posizione.

Ancoraggio dell'operatore passo

`*/N` è ancorato al valore più basso del campo: `*/15` nel minuto = `0,15,30,45`, non "ogni 15 a partire da ora". Con una base non-wildcard: `5/15` nel minuto = `5,20,35,50`. I valori di passo che non dividono uniformemente l'intervallo del campo salteranno vicino al wraparound — è corretto, non un bug.

Limiti di validazione

minuto ∈ [0,59], ora ∈ [0,23], giorno del mese ∈ [1,31], mese ∈ [1,12], giorno della settimana ∈ [0,7]. I valori fuori intervallo producono un errore a livello di campo. Il giorno del mese NON viene validato rispetto al mese (`0 0 31 2 *` viene interpretato senza errori ma non corrisponde mai perché febbraio non ha il giorno 31 — l'anteprima delle prossime esecuzioni mostrerà "Nessuna esecuzione").

Operatori Quartz rifiutati

Cron POSIX non supporta gli operatori Quartz `?` (nessun valore specifico), `L` (last), `W` (giorno feriale più vicino) o `#` (n-esimo giorno della settimana). Questo strumento li rifiuta con un chiaro messaggio "Operatori Quartz non supportati" invece di analizzarli silenziosamente come POSIX non valido. Per pianificazioni Quartz, usa uno strumento consapevole di Quartz o lo scheduler di Spring.

Limite annuale sulla ricerca delle prossime esecuzioni

Il calcolo delle prossime esecuzioni cerca fino a 4 anni in avanti; le espressioni che corrispondono meno spesso (es. pattern "29 febbraio") mostreranno "Nessuna esecuzione nei prossimi 4 anni". È una scelta progettuale per evitare iterazioni illimitate su pattern impossibili.

Best practice per le pianificazioni cron

Usa UTC sui server, converti al momento della visualizzazione

Imposta i tuoi server su UTC (`/etc/timezone` o `TZ=UTC`) e scrivi tutte le espressioni cron in UTC. Converti in ora locale solo al momento della visualizzazione nelle dashboard e nei report. Questo elimina un'intera categoria di bug di fuso orario che colpiscono più duramente durante le transizioni dell'ora legale, quando le pianificazioni in ora locale partono silenziosamente due volte o saltano un'esecuzione. Usa il toggle UTC in questo strumento per progettare la pianificazione in UTC fin dall'inizio.

Evita il trabocchetto OR POSIX di giorno del mese/giorno della settimana

Non restringere mai sia il giorno del mese SIA il giorno della settimana se non vuoi la semantica OR. Se vuoi "ogni lunedì di gennaio", scrivi `0 0 * 1 1` (il giorno del mese è `*`); se vuoi "il primo di ogni mese", scrivi `0 0 1 * *` (il giorno della settimana è `*`). La regola OR POSIX fa sì che `0 0 1 * 1` parta il 1° E ogni lunedì — quasi sicuramente non quello che intendevi. L'anteprima delle prossime esecuzioni cattura questo se controlli prima del deploy.

Fissa esplicitamente il fuso orario della pianificazione

Gli scheduler moderni supportano il pinning del fuso orario nella definizione della pianificazione: `CRON_TZ=America/New_York` in cima a un crontab (vixie cron 3.0+), `spec.timeZone: "America/New_York"` per Kubernetes CronJobs 1.27+, espressione di pianificazione con `ScheduleExpressionTimezone` per AWS EventBridge Scheduler. Fissa il fuso orario esplicitamente invece di affidarti al default del server — i fusi orari dei server possono cambiare senza preavviso durante migrazioni infrastrutturali.

Distribuisci il carico tra i minuti, non a :00

Evita `0 * * * *` (ogni ora al minuto 0) per i job non critici — a scala, pianificare molte cose esattamente a :00 crea picchi di carico. Scegli un offset casuale di minuti (`23 * * * *`, `41 * * * *`) per ogni job per distribuire il carico. Lo stesso vale per i job giornalieri: `30 3 * * *` è più gentile col tuo database di `0 3 * * *` quando molti job convergono alle 3:00.

Rendi i job idempotenti

Cron non ha retry integrato, prevenzione di sovrapposizioni o recupero di esecuzioni perse. Il tuo job dovrebbe poter essere eseguito più volte in sicurezza (idempotente) e auto-controllarsi. Invece di "invia report alle 9", progettalo come "invia il report di oggi se non già inviato" — così si auto-ripara dopo downtime, doppie pianificazioni accidentali ed esecuzioni concorrenti. L'idempotenza è una proprietà del job, non dello scheduler, ed è la singola pratica di affidabilità più importante.

Aggiungi un heartbeat per le pianificazioni critiche

Il fallimento silenzioso è la debolezza più grande di cron — se la pianificazione non parte, niente te lo dice. Per i job critici, fai sì che il job invii un ping a un servizio di heartbeat (Healthchecks.io, Cronitor, Dead Man's Snitch) alla fine di ogni esecuzione; il servizio ti avvisa se il ping atteso non arriva. Questo cattura sia il job che fallisce sia la pianificazione stessa che parte male. Il piano gratuito copre la maggior parte delle esigenze personali e di piccoli team.

Verifica con l'anteprima delle prossime esecuzioni prima di rilasciare

Prima di deployare una nuova pianificazione cron, guarda le cinque date e ore di esecuzione imminenti nell'anteprima di questo strumento. Passa tra Locale e UTC. Conferma che la pianificazione cada quando intendi — non cinque minuti prima, non nel giorno sbagliato, non saltando il weekend che ti interessava. L'anteprima è il test di produzione meno costoso possibile.

Domande frequenti