Générateur d'expressions cron, gratuit

Construisez et comprenez les plannings de tâches cron de manière visuelle.

Préréglages rapides

* * * * *

5 prochaines exécutions

Référence de syntaxe cron

* · n'importe quelle valeur

*/5 · toutes les 5 unités

1,15 · aux valeurs 1 et 15

1-5 · plage de 1 à 5

Champs : minute (0-59), heure (0-23), jour du mois (1-31), mois (1-12), jour de la semaine (0-6, 0=dimanche)

Une brève histoire de l'expression cron

L'expression cron à cinq champs date de mai 1975, quand une première version a été livrée par les AT&T Bell Laboratories dans le cadre de Research Unix Version 7. Le nom est un clin d'œil à Chronos, la personnification grecque du temps. Le format était simple : cinq champs séparés par des espaces (minute, heure, jour-du-mois, mois, jour-de-la-semaine) sur une ligne dans /usr/lib/crontab. La réécriture Vixie cron par Paul Vixie en 1987 est devenue l'implémentation moderne de facto ; toutes les grandes distributions Linux livrent un cron dérivé de Vixie, et Vixie a ajouté le crontab par utilisateur, la prise en charge des variables d'environnement (MAILTO=, CRON_TZ=), et les macros de raccourci @hourly / @daily / @reboot que tout le monde utilise aujourd'hui. La syntaxe de l'expression cron s'est alors divisée en deux voies. Le Quartz Scheduler (Java, James House, 1998 ; donné à Apache puis Terracotta) a ajouté un champ secondes en tête, un champ année optionnel à la fin, et les opérateurs L (last) / W (weekday) / # (nième occurrence), produisant le cron à six champs que AWS EventBridge (à l'origine CloudWatch Events, 2014) et l'annotation @Scheduled de Spring ont ensuite adopté. Le format NCronTab utilisé par Azure Functions (2016) mettait les secondes en premier mais gardait cinq champs comportementaux. L'ère du cloud a ensuite normalisé le format Vixie à cinq champs comme lingua franca : les Kubernetes CronJobs (alpha 1.4 en 2016, GA dans 1.21 en 2021) acceptent exactement cinq champs, tout comme GitHub Actions (on.schedule.cron, 2019), GCP Cloud Scheduler (2018), et Vercel Cron Jobs (2022). Les constructeurs visuels de cron, la catégorie à laquelle appartient cet outil, ont émergé entre 2010 et 2015 : crontab.guru (Christine Dodrill, 2014) est devenu la référence la plus citée, et la bibliothèque cron-descriptor (Brady Holt, à l'origine .NET, portée en Java/Python/JS) a alimenté la plupart des couches de traduction «cron en langage clair» dont dépendent les décodeurs et générateurs. Un demi-siècle après Bell Labs, les mêmes cinq champs planifient toujours les sauvegardes nocturnes du monde entier.

L'anatomie d'une expression cron

Où l'expression s'utilise

Standards, dialectes et jalons

Questions fréquentes supplémentaires

Cinq champs sont-ils la même chose que six ou sept ?

Non. La forme POSIX classique est de cinq champs (minute, heure, jour-du-mois, mois, jour-de-la-semaine). Quartz et Spring utilisent six champs en ajoutant une colonne secondes en tête, et Quartz accepte un septième champ année optionnel. AWS EventBridge utilise toujours six champs se terminant par année (cron(min hr dom mon dow yr)). Coller une expression à cinq champs dans Quartz ou Spring lève une erreur de syntaxe ; coller une expression à six champs dans Linux interprète silencieusement mal les champs.

Quel est le plus petit intervalle que cron peut exprimer ?

Chaque minute (* * * * *) en cron Unix standard. Il n'y a pas de champ secondes intégré. Les ordonnanceurs comme Quartz ou NCronTab en ajoutent un si vous avez besoin d'une cadence inférieure à la minute, et les timers systemd peuvent utiliser OnUnitActiveSec=30s. GitHub Actions plafonne la cadence la plus courte à 5 minutes, et EventBridge se déclenche dans une fenêtre de 60 secondes du temps planifié, donc ne comptez pas sur cron pour une précision temps réel strict.

Comment exécuter une tâche le dernier jour du mois ?

Le cron standard à cinq champs n'a pas d'opérateur natif «dernier jour du mois». Quartz et AWS EventBridge supportent L dans le champ jour-du-mois : 0 0 L * ? se déclenche à minuit le dernier jour. Sur cron Linux pur, le contournement habituel est de planifier quotidiennement sur les jours candidats et de filtrer la commande : 0 0 28-31 * * [ "$(date +\%d -d tomorrow)" = "01" ] && /path/to/script. Les timers systemd l'expriment directement avec OnCalendar=*-*-* 00:00:00.

Pourquoi ma tâche cron ne s'est-elle pas exécutée quand je m'y attendais ?

Les suspects habituels, dans l'ordre : (1) le serveur est dans un fuseau horaire différent de celui que vous supposez (vérifiez avec date) ; (2) PATH n'est pas ce que votre shell interactif a, donc une commande fonctionne à l'invite mais échoue sous cron (utilisez des chemins absolus) ; (3) la sortie est allée par email et vous l'avez manquée (définissez MAILTO="" ou redirigez vers un fichier journal) ; (4) le daemon cron ne tourne pas (systemctl status cron) ; (5) le piège OU (voir ci-dessus) se déclenche sur des jours supplémentaires que vous n'aviez pas prévus.

Quelle est la différence entre cron, anacron, et les timers systemd ?

Cron s'attend à ce que le système soit en marche au moment planifié et saute silencieusement les tâches qui tombent pendant un temps d'arrêt : bien pour les serveurs toujours allumés, mauvais pour les ordinateurs portables. Anacron suit les horodatages de dernière exécution par tâche et rattrape les tâches manquées après un redémarrage, au prix d'une précision au niveau du jour plutôt qu'à la minute. Les timers systemd remplacent cron sur la plupart des distributions Linux modernes : ils supportent les planifications de calendrier et monotones, journalisent dans journald, peuvent déclarer des dépendances de service, et utilisent Persistent=true pour combiner la précision cron avec le rattrapage anacron.

Comment les fuseaux horaires et l'heure d'été affectent-ils cron ?

La plupart des daemons cron interprètent les planifications dans le fuseau horaire du système. Sur les serveurs cloud, cela signifie généralement UTC, donc 0 9 * * * se déclenche à 9h UTC, pas 9h locale. Définissez CRON_TZ=America/New_York dans un crontab Linux ; Kubernetes utilise spec.timeZone ; AWS, GCP, et Vercel prennent chacun un fuseau IANA explicite. Pendant le passage à l'heure d'été, les tâches planifiées dans l'heure sautée sont exécutées immédiatement après par Vixie cron mais sautées entièrement par AWS EventBridge. Le motif le plus sûr est de laisser cron en UTC et de convertir à l'intérieur de la tâche.

Outils associés