ToolActToolAct

Générateur d'Expressions Cron

Générateur et analyseur visuel pour expressions de planification Cron

Cron 表达式
* * * ? * *
每秒钟执行
常用
字段设置
秒 (0-59)
分 (0-59)
时 (0-23)
日 (1-31)
月 (1-12)
周 (0-6)
最近 5 次执行时间
12026-07-04 00:00:00
22026-07-04 00:01:00
32026-07-04 00:02:00
42026-07-04 00:03:00
52026-07-04 00:04:00

Qu'est-ce qu'une Expression Cron ?

Une expression Cron décrit les heures d’exécution récurrentes de tâches planifiées. Selon le planificateur, elle contient cinq, six ou sept champs pour minute, heure, jour du mois, mois, jour de la semaine, secondes optionnelles et année optionnelle. Astérisques, virgules, plages, pas, points d’interrogation et marqueurs spéciaux permettent des règles comme “toutes les 5 minutes”, “les jours ouvrés à 9 h” ou “le dernier jour du mois”. L’outil aide à lire, valider et prévisualiser les prochaines exécutions. Le contexte reste essentiel: Linux cron, Quartz, schedulers cloud et frameworks n’acceptent pas toujours les mêmes champs, fuseaux horaires ni syntaxes.

Comment utiliser

Comment utiliser

  1. Sélectionnez le mode génération ou analyse.
  2. Définissez les champs temporels (seconde, minute, heure, jour, mois, jour de la semaine) via des menus déroulants.
  3. Cliquez sur un préréglage pour remplir rapidement une expression courante.
  4. Le mode génération affiche l'expression et les 5 prochaines exécutions.
  5. Le mode analyse vérifie les expressions existantes et affiche les heures d'exécution.

Symboles de syntaxe

  • * — Toutes les valeurs possibles
  • , — Liste de plusieurs valeurs (ex. : 1,3,5)
  • - — Plage (ex. : 1-5)
  • / — Intervalle de pas (ex. : */5 signifie toutes les 5 unités)
  • ? — Aucune valeur spécifique (pour le jour ou le jour de la semaine)
  • L — Dernier jour du mois/de la semaine
  • W — Jour ouvré le plus proche
  • # — Nième jour de la semaine (ex. : 2#3 = 3ᵉ mardi)

Notes de développement

  • Utilisez le résultat comme référence rapide, puis testez-le dans le contexte réel du code, du build ou de l'API.
  • Prenez en compte les versions, les dialectes, les variables d'environnement et les conventions du projet.

Remarques importantes

  • Les champs jour et jour de la semaine ne peuvent pas être tous les deux renseignés ; l'un doit utiliser ?.
  • Chaque champ a des plages valides : minute 0-59, heure 0-23.
  • L'ordre des champs est fixe : sec min heure jour mois jour_semaine année.
  • Le jour de la semaine est insensible à la casse ; MON et mon sont équivalents.

Cas d’utilisation

Construire des planifications de style Quartz sans mémoriser chaque champUtilisez les contrôles visuels des champs pour assembler une expression à 6 champs avec secondes, minutes, heures, jour, mois et jour de la semaine, incluant les plages, pas, dernier jour, jour ouvré et motifs du nième jour de la semaine. Le constructeur d’expression fonctionne entièrement côté client ; une planification brouillon peut donc être vérifiée par rapport à un fichier de configuration ou à un JSON de tâche planifiée avant d’être validée et poussée.
Analyser une expression cron existante avant déploiementCollez une expression à 5 ou 6 champs pour remplir les contrôles et vérifier si la planification utilise les secondes, le jour du mois, le jour de la semaine ou ? de la manière attendue. Le résultat analysé affiche une description en langage naturel et les prochaines heures d’exécution, ce qui est le moyen le plus rapide de détecter une planification qui se déclenche à minuit alors que la tâche devait s’exécuter pendant les heures ouvrables.
Vérifier les prochaines heures d’exécution par cohérenceConsultez la description générée et les cinq prochaines exécutions avant d’utiliser l’expression pour des tâches, rapports, sauvegardes, rappels ou tâches serveur difficiles à reprogrammer après déploiement. Cela permet de détecter tôt les erreurs de jour de la semaine et les comportements inattendus du champ secondes. Une planification fixée à 0 0 0 29 2 ? pour le 29 février ignorera silencieusement chaque année commune ; l’aperçu analysé rend ce vide visible avant que la tâche ne soit intégrée à un flux de paie ou de clôture de lot.
Tenir compte de la différence entre Linux cron et QuartzUne expression à 5 champs fonctionne sur Linux cron et les démons Unix ; une expression à 6 champs avec secondes fonctionne sur Quartz, Spring et la plupart des planificateurs cloud. Confirmez le système cible avant de sauvegarder, car les mêmes chiffres désignent des planifications différentes. Quartz accepte aussi des raccourcis comme @hourly, @daily, @midnight, @weekly, @monthly, @yearly et @reboot, qui se résolvent en expressions fixes à cinq ou six champs et sont pratiques dans l’annotation @Scheduled de Spring mais rejetés par le crond classique.
Vérifier la gestion du fuseau horaire avant déploiementVérifiez si le planificateur interprète l’expression cron en heure serveur, UTC ou un fuseau nommé comme America/New_York, car une tâche écrite en heure du siège peut se déclencher avec plusieurs heures de retard sur un worker déployé mondialement.

Principe technique

Une expression cron encode zéro ou plusieurs contraintes de correspondance temporelle dans des champs ordonnés de manière fixe. Le cron classique Vixie/BSD (utilisé par Linux crond) comporte 5 champs : minute (0-59), heure (0-23), jour du mois (1-31), mois (1-12 ou JAN-DEC) et jour de la semaine (0-6 ou SUN-SAT, avec dimanche = 0 par convention). Le planificateur Quartz, popularisé par Spring et la bibliothèque Egistix, ajoute un champ secondes en tête pour 6 champs et un champ année optionnel en queue pour 7. Chaque champ peut recevoir une valeur littérale, une liste (1,3,5), une plage (1-5), un pas (0/15 signifiant toutes les 15 unités à partir de 0), ou le joker * qui correspond à toutes les valeurs. Le point d'interrogation ? est un sentinelle spécifique à Quartz signifiant « aucune valeur spécifique » et DOIT apparaître dans exactement l'un des positions jour du mois ou jour de la semaine lorsque l'autre a une contrainte. Le calcul des N prochaines heures d'exécution utilise un algorithme glouton de recherche avant : on part de l'instant de référence (généralement maintenant), on incrémente le champ de niveau le plus bas qui ne correspond pas à la contrainte, on réinitialise tous les champs inférieurs à leur minimum, et on cascade vers les champs supérieurs lorsqu'un champ fait un report (par exemple les minutes au-delà de 59, les heures au-delà de 23). C'est la méthode itérative Donovan/Spoonhour qui s'exécute en O(K x F) où K est le nombre de candidats (généralement 5) et F le nombre de champs. Les noms de jours (MON, FRI, etc.) sont convertis en minuscules et comparés, et les abréviations de mois sont également acceptées. Le caractère spécial L dans Quartz se résout à la dernière occurrence d'un jour de semaine dans le mois (par exemple 0 0 0 ? * 5L est le dernier vendredi), calculé en remontant depuis le dernier jour du mois pour trouver le jour de semaine demandé. Le caractère W trouve le jour ouvrable le plus proche (lundi-vendredi) d'un jour du mois donné, basculant dans le mois adjacent si nécessaire. La gestion des fuseaux horaires est l'erreur de configuration la plus courante : l'expression elle-même ne porte pas de métadonnées de fuseau horaire, donc la même expression 0 0 9 * * ? se déclenche à des décalages UTC différents sur des serveurs dans America/New_York vs. Asia/Tokyo vs. UTC. Les raccourcis comme @daily (0 0 0 * * ?), @hourly (0 0 * * * ?), @reboot (exécution unique au démarrage du démon, pas une expression temporelle) et @weekly (0 0 0 ? * 1) sont étendus en leur forme équivalente à 6 champs avant l'analyse. Un piège courant est la conjonction jour du mois + jour de la semaine : dans le cron classique, la tâche s'exécute lorsque l'un OU l'autre correspond (logique OR), tandis que certains dialectes plus récents passent à la logique AND. L'expression 0 0 0 15 * 5 signifie « à minuit le 15 ET chaque vendredi » en cron Vixie, et non « à minuit le 15 OU le vendredi » comme beaucoup de débutants le supposent. Le problème Y2038 n'affecte pas le cron directement (il utilise time_t), mais tout appareil embarqué exécutant un crond Unix 32 bits débordera de l'entier signé 32 bits time_t le 2038-01-19T03:14:07Z.

  • Classique à 5 champs : min heure jour_mois mois jour_semaine ; Quartz ajoute sec (6 champs) et optionnellement année (7 champs).
  • ? doit occuper l'une des positions jour_mois/jour_semaine lorsque l'autre a une valeur ; * correspond à toutes les valeurs de ce champ.
  • Jour du mois + jour de la semaine est un OU en cron Vixie, un ET dans certains planificateurs plus récents — à vérifier avant le déploiement.
  • L se résout au dernier jour de semaine du mois : par exemple 0 0 0 ? * 5L = dernier vendredi, calculé à partir de la longueur du mois.
  • W trouve le jour ouvrable le plus proche (lundi-vendredi) d'une date donnée ; peut basculer dans le mois adjacent.
  • L'expression cron ne porte pas de métadonnées de fuseau horaire : la même expression se déclenche à l'heure locale du serveur, en UTC ou dans un fuseau nommé selon le planificateur.
  • Y2038 : le time_t 32 bits déborde le 2038-01-19 03:14:07 UTC ; les crond sur les systèmes embarqués legacy seront affectés.
  • Les raccourcis @hourly/@daily/@midnight/@weekly/@monthly/@yearly/@reboot s'étendent en expressions équivalentes à 5 ou 6 champs.
  • L'opérateur de pas / compte à partir de la valeur la plus à gauche : 2/3 sur heure se déclenche à 2, 5, 8, 11, 14, 17, 20, 23.
  • Recherche glouton en avant à cinq itérations en O(KxF) pour calculer les N prochaines heures d'exécution à partir d'un instant de référence.

Exemples

Tous les jours à minuit (sauvegarde quotidienne)

Expression  : 0 0 * * *
Signifie    : À 00:00 chaque jour
Prochaines  : 2026-06-11 00:00, 2026-06-12 00:00, 2026-06-13 00:00
Cas d'usage : Sauvegarde de base de données, génération de rapport quotidien

Toutes les 15 minutes (vérification de santé)

Expression  : */15 * * * *
Signifie    : À la minute 0, 15, 30, 45 de chaque heure
Prochaines  : 14:00, 14:15, 14:30, 14:45, 15:00
Cas d'usage : Vérification de santé d'API, sondage de file, tâches de synchronisation

Jours ouvrables à 9h00 (notification d'heures de travail)

Expression  : 0 9 * * 1-5
Signifie    : 09:00 du lundi au vendredi
Prochaines  : Lun 09:00, Mar 09:00, Mer 09:00, Jeu 09:00, Ven 09:00
Cas d'usage : Rappel de stand-up, résumé quotidien Slack

Premier jour de chaque mois à 03:30 (facturation mensuelle)

Expression  : 30 3 1 * *
Signifie    : 03:30 le 1er de chaque mois
Prochaines  : 1 jui 03:30, 1 aoû 03:30, 1 sep 03:30
Cas d'usage : Facturation mensuelle, rotation des logs, archivage

Tous les dimanches à minuit (nettoyage hebdomadaire)

Expression  : 0 0 * * 0
Signifie    : 00:00 chaque dimanche (0 = dimanche dans cron Linux)
Prochaines  : Dim 00:00, Dim 00:00, Dim 00:00
Cas d'usage : Email de rapport hebdomadaire, purge de cache, ré-entraînement

Quartz avec secondes - toutes les 30 secondes

Expression  : */30 * * * * ?
Signifie    : Toutes les 30 secondes (syntaxe Quartz à 6 champs)
Prochaines  : 14:00:00, 14:00:30, 14:01:00, 14:01:30
Note        : Le jour de la semaine est ?, car le jour du mois est *. Utilisez Quartz, pas cron Linux, pour ce format.

FAQ

Quels formats cron sont pris en charge ?

Le cron standard à 5 champs (minute heure jourDuMois mois jourDeLaSemaine), le format à 6 champs avec secondes (utilisé par Quartz, Spring et de nombreux planificateurs cloud), et le format à 7 champs avec année optionnelle. La page vous permet de choisir le format et explique chaque champ pendant la construction de l'expression.

Pourquoi dayOfMonth et dayOfWeek sont-ils tous deux des champs ?

Le cron standard les traite comme un OU : « premier jour du mois OU chaque lundi » se déclenche à l'une ou l'autre condition. Pour un ET, il faut généralement une syntaxe non standard avec ? (Quartz) ou un contournement. La page affiche les prochaines exécutions pour vérifier visuellement votre intention.

Le planning va-t-il vraiment s'exécuter sur mon système ?

Non : cette page génère et valide l'expression, mais le job s'exécute dans votre planificateur (cron Linux, GitHub Actions, Kubernetes CronJob, AWS EventBridge, Quartz, etc.). Différents planificateurs ont des dialectes cron légèrement différents ; choisissez le bon format pour votre cible.

Quel fuseau horaire utilise le planning ?

Le cron Unix standard utilise le fuseau horaire local du système. Les planificateurs cloud varient : AWS EventBridge utilise UTC par défaut, GitHub Actions utilise UTC par défaut, Kubernetes CronJob utilise le fuseau horaire du serveur API. Lisez la documentation de votre planificateur et rappelez-vous que les transitions d'heure d'été peuvent déclencher des jobs à des moments inattendus.

Comment exprimer « toutes les 30 minutes » ?

*/30 * * * * (minute = 0,30 ; chaque heure, jour, mois, jour de la semaine). Pour « toutes les 15 minutes uniquement pendant les heures ouvrables » : */15 9-17 * * 1-5 (limite aussi à 9h-17h du lundi au vendredi). La page affiche les 5 à 10 prochaines exécutions pour confirmer.

Est-ce sûr de l'utiliser pour de vrais plannings de production ?

La page ne fait que générer l'expression ; l'exécution du job revient à votre planificateur. Testez d'abord l'expression avec une exécution d'essai (la plupart des planificateurs ont une option « exécution manuelle »), et évitez de planifier des jobs à minuit (00:00), où les jobs de nombreux systèmes se chevauchent et provoquent des pics de charge.

Quelque chose est-il envoyé en ligne ?

Non. L'expression est analysée et les prochaines exécutions sont calculées dans votre navigateur à l'aide d'une bibliothèque cron en JavaScript.