Aller au contenu
Aback Tools Logo

Résolveur Cron : Comprendre les Expressions Cron

Comment lire, écrire et valider des expressions cron : syntaxe champ par champ, caractères spéciaux, modèles de planification courants, différences entre plateformes, pièges fréquents et outils gratuits pour résoudre et simuler des planifications.

DH
Tutorials & How-Tos12 min de lecture2,700 mots

Les expressions cron paraissent cryptiques au premier regard - cinq champs séparés par des espaces, remplis d'astérisques, de chiffres, de barres obliques et de virgules. Mais chaque field suit une logique cohérente et, une fois comprise, lire et écrire des planifications cron devient simple. Ce guide décompose chaque partie de la syntaxe cron, explique les caractères spéciaux, présente les modèles de planification les plus courants et couvre les outils qui résolvent, valident et simulent les expressions cron avant leur déploiement.

5Champs cron standardminute, heure, jour du mois, mois, jour de la semaine
15+Préréglages de planification intégrésdans le Crontab Expression Builder
12moHorizon de simulationdans l'Interactive Cron Scheduler

Qu'est-ce qu'une expression cron ?

Une expression cron est une chaîne de cinq (ou parfois six) champs séparés par des espaces qui définit une planification récurrente pour des tâches automatisées. Le format a été inventé avec le démon cron d'Unix au début des années 1970 et n'a pratiquement pas changé depuis. Aujourd'hui, il est utilisé dans les fichiers crontab Linux, les pipelines CI/CD comme GitHub Actions et GitLab CI, les planificateurs cloud comme AWS EventBridge et Google Cloud Scheduler, les orchestrateurs de conteneurs comme Kubernetes CronJob, ainsi que dans des frameworks applicatifs comme Spring et Quartz.

L'anatomie d'une expression cron

Le format standard à cinq champs est le suivant :

format d’une expression cron
text
┌----------- minute        (0-59)
│ ┌--------- heure          (0-23)
│ │ ┌------- jour du mois  (1-31)
│ │ │ ┌----- mois         (1-12)
│ │ │ │ ┌--- jour de la semaine   (0-7, dimanche = 0 ou 7)
│ │ │ │ │
* * * * *   commande à exécuter

Les champs se lisent de gauche à droite : minute, heure, jour du mois, mois, jour de la semaine. L'expression « 0 9 * * 1-5 » se déclenche à 09:00 chaque jour ouvré. Chaque champ peut contenir une valeur unique, une liste séparée par des virgules, une plage, un pas, un joker ou une combinaison. Comprendre ces opérateurs constitue toute la compétence de lecture de cron.

Note

Certaines plateformes utilisent un format à 6 champs qui ajoute un champ des secondes en position 0 (avant les minutes). Spring Scheduler et Quartz utilisent ce format. AWS EventBridge et la plupart des démons cron Unix utilisent 5 champs. Vérifiez toujours le format attendu par votre plateforme cible - une expression écrite pour l'une peut produire silencieusement une planification incorrecte sur l'autre.

Syntaxe des expressions cron champ par champ

Chaque champ possède une plage définie de valeurs entières valides. Les valeurs hors plage produisent une erreur ou une mauvaise configuration silencieuse selon l'implémentation de cron. Comprendre la plage valide de chaque champ est le fondement de la lecture de toute expression cron.

Plages valides des champs

  • Minute - de 0 à 59. La valeur 0 correspond au début de l'heure ; la valeur 59 correspond à une minute avant l'heure suivante.
  • Heure - de 0 à 23. Format 24 heures : 0 est minuit, 12 est midi, 23 est 11 PM.
  • Jour du mois - de 1 à 31. Les jours sont indexés à partir de 1. Certains mois ont moins de jours - février compte 28 ou 29 jours, avril/juin/septembre/novembre en comptent 30.
  • Mois - de 1 à 12. Janvier est 1, décembre est 12. Certaines implémentations acceptent aussi les abréviations de trois lettres : JAN, FEB, MAR, etc.
  • Jour de la semaine - de 0 à 7. 0 et 7 représentent tous deux le dimanche. Lundi est 1, samedi est 6. Certaines implémentations prennent en charge MON, TUE, WED, THU, FRI, SAT, SUN.

Comment les champs interagissent

Les cinq champs sont évalués ensemble comme un ET logique - le job s'exécute lorsque tous les champs sans joker correspondent simultanément. « 0 9 15 * * » se déclenche exactement à 09:00 le 15 de chaque mois. L'exception critique survient lorsque le jour du mois et le jour de la semaine sont tous deux des valeurs sans joker - dans ce cas, la plupart des démons cron se déclenchent si L'UNE DES conditions est vraie (un OU logique), pas les deux. C'est une source notoire de comportements inattendus.

Warning

Le comportement OU entre jour du mois et jour de la semaine est l'un des pièges cron les plus courants. « 0 9 1 * 1 » ne signifie PAS « le premier lundi du mois à 09:00 » - il signifie « 09:00 le 1er du mois, OU 09:00 n'importe quel lundi ». Utilisez un script ou un planificateur géré avec une logique consciente du calendrier si vous avez besoin de la véritable sémantique « premier lundi du mois ».

Les caractères spéciaux expliqués

La puissance de cron vient de ses caractères spéciaux - les opérateurs qui transforment des valeurs fixes en modèles de planification flexibles. Maîtriser ces six opérateurs couvre pratiquement tous les modèles de planification que vous rencontrerez.

Les six opérateurs principaux

CaractèreNomExempleSignification
*Joker* dans minuteToutes les valeurs valides (0-59 pour les minutes)
,Liste1,15,30 dans minuteAux minutes 1, 15 et 30
-Plage1-5 dans jour de semaineDu lundi au vendredi (jours 1 à 5)
/Pas*/15 dans minuteToutes les 15 minutes (0, 15, 30, 45)
?Non-spécifié? dans jour du moisAucune valeur spécifique (Quartz/Spring uniquement)
@Macro@dailyAlias abrégés (@daily = 0 0 * * *)

Combiner les opérateurs

Les opérateurs peuvent être combinés au sein d'un même champ. « 0,30 9-17 * * 1-5 » signifie « aux minutes 0 et 30 de chaque heure de 9 h à 17 h, du lundi au vendredi ». La syntaxe de pas s'applique aussi à une plage : « 0-30/5 » dans le champ des minutes signifie toutes les 5 minutes de la minute 0 à la minute 30 (0, 5, 10, 15, 20, 25, 30). Le Traducteur Cron en Langage Naturel décompose toute combinaison en langage clair avec des explications champ par champ.

Tip

Lors de la lecture d'une expression cron inconnue, analysez chaque champ de gauche à droite et traduisez-le indépendamment. D'abord le champ des minutes, puis l'heure, puis le jour du mois, puis le mois, puis le jour de la semaine. Lisez chaque champ sans astérisque comme une contrainte : « seulement quand minute = X », « seulement quand heure = Y », etc. Le résultat se lit comme une phrase lorsqu'il est assemblé dans l'ordre inverse, de droite à gauche.

Modèles de planification cron courants

La majorité des planifications cron réelles relèvent d'une poignée de modèles récurrents. Connaître ces modèles de vue permet de lire la plupart des crontabs de production sans référence.

  1. "* * * * *" - Chaque minute. La planification la plus fréquente possible. Utilisée pour les vérifications de pulsation et la supervision.
  2. "*/5 * * * *" - Toutes les 5 minutes. Courant pour les tâches de sondage et le préchauffage de cache.
  3. "0 * * * *" - Chaque heure pile. Standard pour les traitements par lots horaires.
  4. "0 0 * * *" - Tous les jours à minuit (UTC). Le réglage par défaut des tâches de nettoyage quotidien.
  5. "0 9 * * 1-5" - 9 h chaque jour ouvré. Planification standard aux heures de bureau.
  6. "0 0 1 * *" - Minuit le 1er de chaque mois. Exécutions de facturation mensuelle, génération de rapports.
  7. "0 0 1 1 *" - Minuit le 1er janvier. Tâches annuelles - renouvellements de licences, rapports de fin d'année.
  8. "0 0 * * 0" - Minuit chaque dimanche. Fenêtres de maintenance hebdomadaires.

Construire des planifications personnalisées à partir de modèles

La plupart des planifications complexes sont des combinaisons de ces modèles. « 0 2 * * 6,0 » signifie « 2 h le samedi et le dimanche » - la fenêtre de maintenance du week-end. « */10 8-18 * * 1-5 » signifie « toutes les 10 minutes de 8 h à 18 h, jours ouvrés uniquement ». Si vous connaissez la planification cible en langage clair, le Crontab Expression Builder vous permet de configurer chaque champ visuellement et génère l'expression correcte avec une confirmation lisible et les cinq prochaines exécutions.

Crontab Expression Builder

Créez des expressions cron visuellement avec 15 préréglages, 5 modes de champ, une description instantanée en langage clair et un aperçu des 5 prochaines exécutions - gratuit, sans inscription.

Open tool

Comment créer et valider des expressions cron

Écrire une expression cron from scratch en espérant qu'elle soit correcte est risqué. Un seul champ transposé ou un opérateur mal compris peut déclencher un job à des moments complètement erronés - ou jamais. Ces outils éliminent ce risque.

1

Écrivez ou sélectionnez votre expression

Ouvrez le Crontab Expression Builder et tapez votre expression directement ou choisissez parmi les 15 préréglages intégrés. Chaque préréglage couvre un modèle de planification courant (chaque minute, horaire, quotidien, jours ouvrés, mensuel) et peut être ajusté à l'aide des contrôles visuels sans toucher à l'expression brute.

2

Validez les erreurs de syntaxe

Collez l'expression dans le Validateur d'Expressions Cron. Il vérifie chaque champ par rapport à sa plage valide, valide les bornes des plages (le début doit être inférieur à la fin), confirme que les valeurs de pas sont non nulles et signale les macros non prises en charge par le crontab standard à 5 champs. Chaque erreur s'accompagne d'un message au niveau de la ligne expliquant ce que l'analyseur attendait.

3

Traduisez en langage clair

Passez l'expression validée dans le Traducteur Cron en Langage Naturel. La sortie est une phrase complète en langage clair décrivant la planification - « À 2 h 30, le lundi, mercredi et vendredi » - plus une décomposition champ par champ. Si la description ne correspond pas à votre intention, révisez l'expression avant de déployer.

4

Simulez les 12 prochains mois d'exécutions

Pour les tâches planifiées où le rythme importe - exécutions de facturation, exports de données, fenêtres de maintenance - ouvrez l'Interactive Cron Scheduler et simulez l'expression sur les 12 prochains mois. La vue calendrier affiche la densité mensuelle des exécutions et la chronologie montre les horodatages exacts. Confirmez que la planification se déclenche aux dates attendues avant de fusionner la configuration en production.

Validateur d'Expressions Cron

Validez la syntaxe cron à 5 champs, les plages, les pas, les valeurs de liste et les macros avec des diagnostics instantanés au niveau des champs - local au navigateur, gratuit, sans inscription.

Open tool

Cron dans la CI/CD et les planificateurs cloud

La syntaxe cron est utilisée bien au-delà du crontab Linux. Les plateformes CI/CD et cloud modernes ont toutes adopté le même format à 5 champs, mais chacune a ses propres particularités concernant la gestion des fuseaux horaires, la prise en charge des macros et les restrictions d'intervalle minimal.

Différences plateforme par plateforme

PlateformeChampsFuseau horaireMacrosIntervalle min.
Linux crontab5Heure locale système✓ Les 6Chaque minute
GitHub Actions5UTC uniquement✗ AucuneToutes les 5 min (dérive forcée de 15 min)
GitLab CI5UTC uniquement✓ PartielleChaque minute
AWS EventBridge5 ou 6UTC uniquement✗ AucuneChaque minute
Google Cloud Scheduler5 ou unixN'importe quel fuseau IANA✓ CertainesChaque minute
Kubernetes CronJob5Fuseau du cluster✗ AucuneChaque minute
Spring Scheduler6Réglage JVM par défaut✓ OuiChaque seconde

Planification cron avec GitHub Actions

GitHub Actions utilise la syntaxe cron standard à 5 champs mais s'exécute toujours en UTC. Si vous voulez un job à 9 h heure de l'Est (UTC-5), vous écrivez « 0 14 * * * ». GitHub Actions ne prend pas non plus en charge la syntaxe des macros (@daily, @weekly), utilisez donc l'expression complète. Les workflows planifiés pendant les périodes de forte charge peuvent se déclencher jusqu'à 15 minutes en retard - concevez vos jobs pour tolérer cette dérive.


Convertir cron en minuteurs systemd

Les systèmes Linux modernes utilisent de plus en plus de minuteurs systemd à la place du crontab classique. Le format OnCalendar de systemd utilise une syntaxe différente mais couvre les mêmes modèles. Le Convertisseur Cron vers Minuteur Systemd convertit toute expression cron à 5 champs en configuration d'unité de minuteur systemd équivalente, avec un modèle complet de fichiers .timer et .service.

Pièges et cas limites de cron

Même les développeurs expérimentés rencontrent des échecs silencieux avec cron. Voici les pièges les plus courants - chacun a coûté à des systèmes de production des indisponibilités inaperçues ou des exécutions de jobs dupliquées.

Surprises de fuseau horaire

Cron s'exécute par défaut dans le fuseau horaire local du serveur. Si votre serveur est en UTC mais votre entreprise à New York (UTC-5), « 0 9 * * * » se déclenche à 4 h heure locale, pas à 9 h. Les plateformes cloud comme GitHub Actions et AWS EventBridge s'exécutent toujours en UTC, ce qui signifie que tous les calculs de fuseaux horaires vous incombent. Confirmez toujours le fuseau horaire avant de déployer une planification. L'Interactive Cron Scheduler permet de simuler des exécutions avec le décalage horaire appliqué.

Cas limites de fin de mois

Planifier une tâche le 29, 30 ou 31 du mois la fait sauter silencieusement les mois qui n'ont pas cette date. « 0 0 31 * * » ne s'exécute jamais en avril, juin, septembre ou novembre. « 0 0 29 2 * » s'exécute en février uniquement les années bissextiles. Si vous avez besoin d'une planification « dernier jour du mois », il faut une approche plus intelligente - soit exécuter quotidiennement avec un script qui vérifie la date, soit utiliser un planificateur cloud qui prend en charge la syntaxe L (dernier) jour.

Transitions heure d'été

Les transitions d'heure d'été peuvent faire s'exécuter des jobs cron deux fois ou les faire sauter. Quand les horloges avancent, les heures dans l'heure sautée ne se produisent jamais. Quand les horloges reculent, les heures dans l'heure répétée se produisent deux fois. Les jobs planifiés dans un fuseau horaire local pendant la fenêtre de transition sont affectés. La pratique la plus sûre consiste à faire tourner serveurs et planificateurs en UTC, qui n'a jamais de transitions d'heure d'été.

Warning

Ne comptez jamais sur cron pour une exécution unique et critique dans le temps. Les démons cron peuvent manquer une exécution si le système est hors service, redémarre, sous forte charge ou si l'horloge est ajustée. Pour les transactions financières, une conception de job idempotente et une file de jobs avec gestion des lettres mortes sont plus fiables que la planification cron brute.

Le problème du chaque-seconde

Le cron standard à 5 champs a une résolution minimale d'une minute. Si vous avez besoin d'un job toutes les 10 secondes, cron n'est pas le bon outil - utilisez un minuteur système, une file de jobs avec délais ou le champ des secondes disponible dans Spring Scheduler et Quartz. Tenter d'approcher des planifications inframinutes avec plusieurs entrées crontab est source d'erreurs et crée des conditions de concurrence lorsque les jobs se chevauchent.

Key takeaways

  • Une expression cron comporte cinq champs : minute (0-59), heure (0-23), jour du mois (1-31), mois (1-12), jour de la semaine (0-7).
  • Les six caractères spéciaux sont * (joker), , (liste), - (plage), / (pas), ? (non-spécifié, Quartz uniquement) et @ (macros comme @daily).
  • Lorsque le jour du mois et le jour de la semaine sont tous deux sans joker, la plupart des démons cron se déclenchent si L'UN des deux correspond - une source fréquente de doubles exécutions inattendues.
  • Utilisez le Crontab Expression Builder pour construire visuellement, le Validateur d'Expressions Cron pour vérifier la syntaxe et l'Interactive Cron Scheduler pour simuler 12 mois d'exécutions.
  • GitHub Actions utilise un cron à 5 champs UTC sans prise en charge des macros ; AWS EventBridge et Google Cloud Scheduler utilisent aussi UTC ; le crontab Linux utilise le fuseau horaire local du système.
  • Ne planifiez pas le 29, 30 ou 31 si le job doit s'exécuter chaque mois - ces jours n'existent pas dans tous les mois.
  • Le cron standard a une résolution minimale d'une minute ; utilisez des minuteurs systemd, des files de jobs ou Spring/Quartz pour les besoins de planification inframinute.

Questions fréquentes

A cron resolver is a tool that parses a cron expression and translates it into a human-readable schedule description and a list of the next scheduled run times. Given an expression like "0 9 * * 1-5", a resolver tells you "At 09:00 AM, Monday through Friday" and shows you the next five dates and times the job will fire. The Aback Tools Cron to Human-Readable Translator and Interactive Cron Scheduler both perform this resolution instantly in your browser without uploading anything to a server.

The five fields are minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7, where both 0 and 7 represent Sunday). They run left to right in that order. The expression "30 8 * * 1" means "At 8:30 AM, every Monday." An asterisk (*) in any field means "every valid value for that field." Most standard crontab implementations use exactly these five fields; some extended formats (Spring Scheduler, Quartz) add a sixth seconds field at the start.

An asterisk (*) is the wildcard character in cron - it means "match every valid value for this field." In the minute field, * means every minute (0-59). In the hour field, * means every hour (0-23). In the day-of-week field, * means every day. So "* * * * *" runs every minute of every hour every day. It is the broadest possible value for any field. Use it when a field should not restrict the schedule rather than listing every value explicitly.

Range syntax specifies a span of consecutive values: "1-5" in the day-of-week field means Monday through Friday. Step syntax uses a forward slash to specify an interval: "*/15" in the minute field means every 15 minutes (0, 15, 30, 45). They can be combined: "0-30/10" means every 10 minutes from minute 0 to minute 30 (0, 10, 20, 30). Step syntax is commonly used to run jobs at regular intervals without listing every value explicitly.

Use the step syntax in the minute field: "*/5 * * * *". This expression fires at minutes 0, 5, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55 of every hour, every day. If you need to run every 5 minutes but only during business hours (9 AM to 5 PM, Monday to Friday), use "*/5 9-17 * * 1-5". Validate the expression in the Cron Expression Validator and preview the exact fire times in the Interactive Cron Scheduler before deploying.

Cron macros are shorthand aliases for common schedule expressions. The most widely supported are @reboot (run once at startup), @yearly or @annually ("0 0 1 1 *"), @monthly ("0 0 1 * *"), @weekly ("0 0 * * 0"), @daily or @midnight ("0 0 * * *"), and @hourly ("0 * * * *"). Support varies by scheduler - Linux crontab and most Unix cron daemons support all six; AWS EventBridge, Google Cloud Scheduler, and GitHub Actions do not support macro syntax. The Cron to Human-Readable Translator handles macros and expands them to their equivalent expressions.

The most common causes are timezone mismatch (cron runs in the server's local timezone, often UTC), off-by-one in day-of-week numbering (0 and 7 both mean Sunday on most systems, but not all), and the interaction between day-of-month and day-of-week fields (when both are non-wildcard, most cron implementations fire if EITHER condition is true, not both). Use the Interactive Cron Scheduler to simulate the exact fire times in UTC versus your expected timezone before concluding there is a bug.

Yes. GitHub Actions supports cron scheduling via the `schedule` trigger with a `cron:` key using standard 5-field cron syntax. GitHub Actions runs on UTC, so adjust your expression accordingly. Note that GitHub Actions does not support cron macros (@daily, @weekly, etc.) - use the full 5-field expression instead. Also, scheduled workflows may not run at exactly the specified time during periods of high load; expect up to 15 minutes of drift. The Crontab Expression Builder generates GitHub Actions-compatible expressions with next run time previews.

ShareXLinkedIn