Analyseur d'expressions Cron

Analyseur d'expressions Cron - Lire et expliquer vos plannings

Un puissant analyseur Cron en ligne qui vous aide à comprendre, valider et documenter les expressions de planification. Il gère les formats Unix/Linux (5 champs) et Quartz (6-7 champs), fournit une description détaillée champ par champ et affiche les prochaines exécutions pour sécuriser vos automatisations.

Qu'est-ce qu'une expression cron et comment la lire?

Une expression cron est une chaîne de 5 ou 6 champs qui définit quand une tâche récurrente doit s'exécuter. Le cron Unix standard a 5 champs: minute (0-59), heure (0-23), jour du mois (1-31), mois (1-12), jour de la semaine (0-6, dimanche est 0 ou 7). De nombreux ordonnanceurs plus récents (Quartz, Spring, Jenkins, AWS EventBridge) ajoutent un 6e champ de secondes à l'avant et un 7e champ d'année à la fin. La chaîne "0 9 * * 1-5" signifie "à 09:00 du lundi au vendredi." Le caractère * signifie "toute valeur," / signifie "pas" (*/15 = tous les 15), - signifie plage (1-5), et , signifie liste (1,3,5). La page man de Vixie cron est la référence canonique pour le format original à 5 champs, RFC 4954 couvre certaines sémantiques d'ordonnancement, et la doc Quartz couvre le dialecte étendu.

Comment trouver la prochaine exécution d'une expression cron?

Collez l'expression dans l'analyseur et lisez la carte « Prochaines exécutions » — elle liste les 5 à 10 prochains déclenchements ainsi qu'un compte à rebours en direct jusqu'au plus proche. Important : choisissez d'abord le bon fuseau horaire dans la liste déroulante, car cet outil calcule les heures d'horloge correspondantes dans le fuseau que vous sélectionnez (UTC, Asia/Tokyo, etc.), et ne se contente pas de reformater un instant unique ; les exécutions prévues restent donc correctes même si votre navigateur se trouve dans un autre fuseau. Pour vérifier un planning avant un déploiement, basculez le fuseau sur celui de votre serveur ou cluster et confirmez que les prochaines exécutions tombent où vous l'attendez. Les macros comme @daily sont développées en 0 0 * * * et s'affichent normalement ; @reboot n'a pas d'heure d'horloge (il se déclenche une fois au démarrage du daemon) et affiche donc une note de démarrage au lieu d'une liste.

Quelle est la différence entre */5 et 0/5 dans le champ minute?

Les deux signifient "toutes les 5 minutes en commençant à 0," mais y arrivent par des chemins syntaxiques différents. */5 signifie "pas de 5 sur toute la plage," produisant 0, 5, 10, 15, ..., 55. 0/5 est la syntaxe étendue Quartz/Spring qui signifie "commencez à 0, pas de 5," identique en résultat. Cependant, 3/5 signifie explicitement "commencez à 3 puis pas de 5": 3, 8, 13, 18, ..., 58. Le Vixie cron standard ne supporte pas la syntaxe N/M (seulement */M); si vous écrivez 3/5 dans un crontab Linux vanille, cela échouera silencieusement ou sera mal interprété. Vérifiez toujours si votre runtime cible utilise Vixie cron, croniter (Python), node-cron, Quartz ou Spring — ils diffèrent exactement sur ce point. AWS EventBridge en particulier utilise un format à 6 champs de type Quartz et une sémantique de jour de la semaine particulière.

Pourquoi jour du mois et jour de la semaine sont-ils interprétés comme OU, pas ET?

C'est la règle cron la plus surprenante. "0 0 13 * 5" ne signifie PAS "le 13 du mois ET seulement le vendredi" — cela signifie "le 13 de n'importe quel mois, OU n'importe quel vendredi." Quand jour-du-mois et jour-de-la-semaine sont tous deux restreints (aucun n'est *), le Vixie cron classique et la plupart des descendants les traitent comme une union, pas une intersection. Le BSD cron original utilisait l'intersection, mais Vixie cron a délibérément basculé vers l'union en 1992 pour correspondre aux attentes des utilisateurs pour des choses comme "jours ouvrables plus le 1er" ("0 9 1 * 1-5" = 9h les jours ouvrables OU le 1er de chaque mois). Pour obtenir l'intersection réelle (alertes vendredi 13), vous avez généralement besoin d'une protection dans la tâche elle-même, ou utilisez le ? spécial de Quartz dans l'un des champs jour pour désambiguïser. La spécification Quartz exige qu'exactement un parmi jour-du-mois/jour-de-la-semaine soit ? pour rendre cela non ambigu.

Que signifient @reboot, @daily, @weekly, @yearly et @hourly?

Ces surnoms sont des raccourcis définis par Vixie cron pour les horaires courants. @yearly (alias @annually) = 0 0 1 1 * (minuit le 1er janvier). @monthly = 0 0 1 * * (minuit le 1er). @weekly = 0 0 * * 0 (minuit le dimanche). @daily (alias @midnight) = 0 0 * * * (minuit chaque jour). @hourly = 0 * * * * (en début de chaque heure). @reboot est spécial: il s'exécute une fois au démarrage du daemon cron, typiquement au démarrage du système — utile pour les tâches de démarrage de service mais peu fiable dans les environnements conteneurisés où le daemon cron peut redémarrer pour d'autres raisons. Les timers systemd et les Kubernetes CronJobs ne supportent pas @reboot sémantiquement. Certaines saveurs supportent aussi @minutely (chaque minute) mais ce n'est pas standard.

Comment exécuter une tâche toutes les 5 minutes entre 9h et 17h en semaine?

L'expression est "*/5 9-17 * * 1-5" signifiant toutes les 5 minutes (minute 0, 5, 10, ..., 55) des heures 9 à 17, n'importe quel jour du mois, n'importe quel mois, lundi à vendredi. Deux subtilités: ceci déclenche aussi à 17:00, 17:05, ..., 17:55 — pas seulement 17:00. Pour arrêter à 17:00 pile, utilisez "*/5 9-16 * * 1-5" + "0 17 * * 1-5". Aussi, jour-de-la-semaine 1-5 est lundi-vendredi en Linux cron, mais en Quartz et AWS EventBridge, dimanche est 1 et samedi est 7, donc lundi-vendredi est 2-6 — un bug de décalage fréquent. Testez toujours dans votre ordonnanceur cible. Les parseurs cron en ligne comme celui sur cette page affichent les 5-10 prochains horaires d'exécution pour que vous puissiez vérifier l'expression visuellement.

Quelle est la différence entre cron, timers systemd et Kubernetes CronJobs?

Les trois ordonnancent des tâches récurrentes mais avec des garanties différentes. Le cron Unix classique est simple, ubiquitaire, mais n'a pas de logging, ni de suivi de dépendances, ni de réessais, et envoie silencieusement les erreurs par e-mail à root. Les timers systemd sont le remplacement Linux moderne: ils s'intègrent au journal (logs structurés), supportent OnBootSec / OnCalendar (plus riche que la syntaxe cron), gèrent les exécutions manquées (Persistent=true rattrape si le système était éteint) et ont des dépendances d'unité. Les Kubernetes CronJobs utilisent une expression cron à 5 champs de type Quartz mais ajoutent concurrencyPolicy (Allow/Forbid/Replace), startingDeadlineSeconds et des limites d'historique succès/échec. Les ordonnanceurs cloud (AWS EventBridge, GCP Cloud Scheduler, Azure Logic Apps) ajoutent réessais, files de lettres mortes et observabilité. Pour tout ce qui dépasse un serveur de loisir, préférez les timers systemd ou un ordonnanceur cloud plutôt que cron brut.

Quelle est la différence entre L, W et # dans les expressions cron Quartz?

Ce sont des extensions Quartz non trouvées dans le Vixie cron standard. L signifie "dernier": L en jour-du-mois = le dernier jour du mois (gère 28/29/30/31 automatiquement), 5L en jour-de-la-semaine = le dernier vendredi du mois. W signifie "jour ouvrable le plus proche": 15W = le jour ouvrable le plus proche du 15 (si le 15 est samedi, déclenche le vendredi 14; si dimanche, lundi 16). LW combiné = le dernier jour ouvrable du mois — utile pour la paie. # spécifie la Nième occurrence: 2#3 en jour-de-la-semaine = le troisième mardi du mois (puisque Quartz utilise 1=Dim, 2=Lun, ..., 7=Sam). Ces extensions gèrent les règles métier réelles ("deuxième lundi de chaque mois", "dernier jour ouvré pour les factures") que le cron 5-champs pur ne peut exprimer. AWS EventBridge supporte L et # mais pas W.

Comment les fuseaux horaires affectent-ils les horaires cron?

Le Vixie cron classique s'exécute dans le fuseau horaire local du système (variable TZ), ce qui cause des bugs douloureux autour des transitions d'heure d'été. Dans un fuseau avec avance de printemps, les tâches programmées à 02:30 ne s'exécutent simplement pas ce jour-là. Avec recul d'automne, les tâches à 01:30 s'exécutent deux fois. Les timers systemd utilisent UTC par défaut sauf si OnCalendar spécifie un TZ. Quartz et les Kubernetes CronJobs supportent tous deux un champ fuseau horaire explicite (spec.timeZone dans CronJob 1.27+) pour que la même expression se comporte identiquement entre régions. AWS EventBridge interprète cron toujours en UTC; les expressions rate(...) sont indépendantes du fuseau. Bonne pratique: écrivez toutes les expressions cron en UTC et convertissez pour l'affichage. Si vous devez utiliser l'heure locale, évitez les heures de bord de l'heure d'été (02:00-03:00 dans la plupart des régions); programmez les tâches à 04:00 ou plus tard.