← 🛠️ Dev Tools
💾 Dev Tools

Cron Expression Generator

Crea e spiega espressioni cron con un builder visuale. Incolla un'espressione esistente per capirla, o usa i preset per le schedulazioni più comuni.

Preset comuni:
0-59, */5, 0,30
0-23, */2, 8-18
1-31, */10
1-12, JAN-DEC
0-7, MON-SUN
0 * * * *

📖 Spiegazione

Come si legge un'espressione cron

Un'espressione cron è composta da 5 campi separati da spazio: minuto ora giorno-del-mese mese giorno-della-settimana. Il carattere * significa "ogni", / definisce intervalli, , elenca valori multipli e - definisce un range. Esempio: 30 8 * * 1-5 significa "alle 8:30 ogni giorno lavorativo (lunedì–venerdì)". Il generatore visuale elimina la necessità di memorizzare la sintassi: selezioni le opzioni e l'espressione viene costruita automaticamente.

Espressioni cron più usate

* * * * * — ogni minuto. 0 * * * * — ogni ora in punto. 0 0 * * * — ogni giorno a mezzanotte. 0 9 * * 1-5 — ogni giorno lavorativo alle 9:00. 0 0 * * 0 — ogni domenica a mezzanotte. 0 0 1 * * — il primo di ogni mese a mezzanotte. */15 * * * * — ogni 15 minuti. 0 6,12,18 * * * — alle 6, 12 e 18 ogni giorno. 0 0 1 1 * — il 1° gennaio a mezzanotte (task annuale). @reboot — all'avvio del sistema (sintassi speciale supportata da crontab).

Cron esteso a 6 campi: secondi e anni

Il cron standard Unix usa 5 campi (senza secondi). Sistemi e framework come Spring Boot, Quartz Scheduler (Java), node-cron e GitHub Actions usano varianti con 6 campi — il primo campo aggiuntivo rappresenta i secondi. In GitHub Actions on: schedule: cron usa la sintassi a 5 campi in UTC. AWS CloudWatch Events usa la sintassi a 6 campi con un campo year opzionale. Verifica sempre quale variante usa il tuo sistema prima di scrivere l'espressione.

Testare un'espressione cron senza rischi

Prima di deployare, verifica che l'espressione faccia quello che pensi usando il Cron Visualizer — mostra le prossime N esecuzioni programmate con data e ora esatta. Su Linux/macOS puoi testare il comando del cron manualmente dalla shell nello stesso utente che lo eseguirà — se funziona lì, funzionerà nel cron. Aggiungi sempre il redirect dell'output in un log: 0 2 * * * /script.sh >> /var/log/myjob.log 2>&1. Senza redirect, i messaggi di errore vengono inviati via email all'utente di sistema (spesso ignorata) o persi del tutto.

Errori comuni nelle espressioni cron

PATH mancante: il cron usa un PATH minimale — comandi che funzionano nella shell interattiva (es. python3, node) potrebbero non essere trovati. Soluzione: usa sempre percorsi assoluti (/usr/bin/python3) o definisci PATH nelle prime righe del crontab. Variabili d'ambiente assenti: il cron non carica .bashrc.profile — le variabili d'ambiente impostate lì non sono disponibili. Definiscile direttamente nel crontab o all'inizio dello script. Timezone sbagliata: il cron usa il timezone del sistema — se il server è in UTC e tu ragioni in CET (UTC+1), l'espressione 0 9 * * * esegue alle 10:00 ora italiana. Verifica con timedatectl su Linux.

Cron vs systemd timer: quando usare quale

Su sistemi Linux moderni (Ubuntu 20+, Debian 10+, RHEL 8+), i systemd timer sono l'alternativa nativa al cron. Vantaggi dei timer: logging integrato via journald (journalctl -u mytimer), dipendenze tra unit, esecuzione al boot se un'esecuzione è stata persa (Persistent=true), monitoraggio dello stato con systemctl status. Usa cron per: script semplici e veloci, ambienti non-systemd, compatibilità con sistemi legacy, task cross-sistema. Usa systemd timer per: task complessi con dipendenze, produzione su sistemi moderni, audit e monitoraggio integrato.

FAQ

Come eseguire un cron ogni 30 secondi?

Il cron standard non supporta la granularità in secondi. Il workaround classico: * * * * * /script.sh && sleep 30 && /script.sh — esegue lo script, aspetta 30 secondi, riesegue, tutto dentro il singolo minuto. Per granularità in secondi usa un processo sempre attivo con sleep interno, un job worker (Celery, BullMQ) o systemd timer con OnCalendar=*:*:0/30.

Il cron gira se il server è spento?

No — se il server è spento all'orario programmato, l'esecuzione viene saltata silenziosamente. Con systemd timer e Persistent=true, il task viene eseguito alla prossima accensione se l'orario è passato. Per task critici su sistemi cloud usa servizi gestiti come AWS EventBridge, Google Cloud Scheduler o Heroku Scheduler che garantiscono l'esecuzione indipendentemente dallo stato del server.

Come vedere i log di un cron job?

Senza redirect: su molti sistemi i log finiscono in /var/log/syslog o /var/log/cron — cerca con grep CRON /var/log/syslog. Con redirect (consigliato): aggiungi >> /percorso/log.txt 2>&1 al comando nel crontab per catturare sia stdout che stderr nel file di log.

Come editare il crontab?

Usa crontab -e per editare il crontab dell'utente corrente (apre l'editor di default). crontab -l mostra il crontab attuale. crontab -r rimuove il crontab (attenzione — senza conferma). Per task di sistema che girano come root usa i file in /etc/cron.d/ o /etc/crontab.