Analyseur d'expressions Cron
Lisez une expression cron en anglais simple et voyez exactement quand elle se déclenchera la prochaine fois.
minute · heure · jour du mois · mois · jour de la semaine. Les macros comme @daily fonctionnent aussi.
Cela s’exécute
à 03:00, le lundi
Les six prochaines exécutions · UTC
- 2026-09-21 03:00lundi
- 2026-09-28 03:00lundi
- 2026-10-05 03:00lundi
- 2026-10-12 03:00lundi
- 2026-10-19 03:00lundi
- 2026-10-26 03:00lundi
Affiché en UTC. Un vrai crontab tourne dans le fuseau horaire du serveur, et c’est là que l’heure d’été pose problème — voir plus bas.
Champ par champ
- minute
- 00
- heure
- 33
- jour du mois
- *n’importe lequel
- mois
- *n’importe lequel
- jour de la semaine
- 11
Ce qu’il faut savoir de cette planification
- Le 31 n’existe pas dans tous les mois : ces mois-là, cela ne s’exécutera tout simplement pas.
- Le 29 février n’existe que les années bissextiles — cela s’exécute donc une fois tous les quatre ans.
Cinq champs, du plus fin au plus grossier
| Position | Champ | Plage | Remarques |
|---|---|---|---|
| 1 | Minute | 0–59 | |
| 2 | Heure | 0–23 | Horloge de 24 heures, heure du serveur |
| 3 | Jour du mois | 1–31 | Les jours qui n’existent pas sont simplement sautés |
| 4 | Mois | 1–12 | Ou JAN–DEC |
| 5 | Jour de la semaine | 0–7 | 0 et 7 désignent tous deux le dimanche. Ou SUN–SAT |
À l’intérieur d’un champ : * signifie n’importe lequel, , énumère des valeurs, - donne une plage et / indique un pas. */15 dans le champ des minutes, c’est toutes les quinze minutes ; 5/10 signifie à partir de 5, de dix en dix, soit 5, 15, 25, et ainsi de suite. Les plages peuvent boucler : FRI-MON est donc une façon valide de dire le week-end et ses bords.
La règle qui piège tout le monde
C’est la seule chose qu’il faut retenir de cette page.
Quand les deux champs — jour du mois et jour de la semaine — sont restreints, cron lance la tâche dès que l’un des deux correspond. Pas les deux. C’est un OU, et cela se lit comme un ET.
0 0 1 * MON # NOT "the 1st, if it is a Monday"
# Actually: every 1st, AND every MondayCette planification se déclenche environ cinq fois par mois. Collez-la dans l’analyseur ci-dessus et regardez les prochaines exécutions : la suite la trahit immédiatement.
La règle ne s’applique que si les deux champs sont restreints. Si l’un vaut *, l’autre commande tout simplement — c’est pourquoi 0 0 * * MON se comporte exactement comme prévu. Ce comportement figure dans la spécification POSIX et tous les cron courants l’implémentent : ce n’est donc pas un défaut que l’on peut désactiver par configuration.
Pour exiger réellement les deux conditions, restreignez un champ dans la planification et vérifiez l’autre au début de la tâche :
0 0 * * MON [ "$(date +\%d)" = "01" ] && /usr/local/bin/jobL’heure d’été, qui casse des tâches deux fois par an
Cron s’exécute dans le fuseau horaire local du serveur sauf indication contraire, et l’heure locale n’est pas continue. Quand les horloges avancent, une heure disparaît : une tâche prévue à 02:30 peut être purement sautée ou déclenchée à 03:30, selon le cron dont vous disposez. Quand les horloges reculent, 01:30 se produit deux fois — et la tâche aussi, éventuellement.
Le Vixie cron moderne fait un effort — les tâches manquées à cause d’un saut en avant sont généralement exécutées une fois ensuite — mais le comportement n’est pas cohérent d’une implémentation à l’autre, et les planificateurs de conteneurs varient encore.
Le correctif durable consiste à faire tourner le planificateur en UTC et à convertir aux extrémités. Les CronJobs de Kubernetes sont en UTC par défaut exactement pour cela. Si une tâche doit s’exécuter à une heure locale précise, acceptez qu’elle soit décalée d’une heure une partie de l’année, ou employez un planificateur qui comprend vraiment les fuseaux — les minuteurs systemd, eux, le font.
Autres raisons pour lesquelles une tâche cron ne s’exécute pas
- L’environnement est quasiment vide. Cron ne charge pas votre profil de shell : le
PATHest minimal et votre environnement virtuel n’est pas actif. Utilisez des chemins absolus, toujours. - Un signe pour cent isolé. Dans un crontab,
%signifie saut de ligne.date +%Ycasse en silence ; il faut écriredate +\%Y. - Pas de saut de ligne final. Certains cron ignorent la dernière ligne d’un crontab qui ne se termine pas par un saut de ligne.
- La sortie ne va nulle part. Cron envoie la sortie par courrier à l’utilisateur, et si le courrier n’est pas configuré, elle s’évapore. Redirigez-la vers un fichier journal pour que les échecs soient visibles.
- Des exécutions qui se chevauchent. Cron n’attend pas la fin de l’exécution précédente. Une tâche de cinq minutes planifiée toutes les minutes s’accumule jusqu’à ce que quelque chose lâche. Utilisez
flock.
Ce que cron ne sait pas exprimer
Les champs sont indépendants : tout ce qui ne divise pas exactement une heure ou une journée est hors de portée. « Toutes les 90 minutes » ne s’écrit pas. Pas davantage « le dernier vendredi du mois » en cron standard — c’est à cela que servent le L et le # de Quartz, et c’est pourquoi ils ne sont pas portables.
Si vous vous retrouvez à lutter contre la syntaxe, c’est en général le signal qu’il faut passer à un planificateur qui raisonne en intervalles plutôt qu’en champs de calendrier. Un minuteur systemd avec OnUnitActiveSec=90min dit ce que vous vouliez dire en une seule ligne.
À voir aussi
Les heures d’exécution ci-dessus sont en UTC — le convertisseur d’horodatage vous en donnera n’importe laquelle dans votre propre fuseau, ou dans le format qu’enregistre votre planificateur. Pour reconnaître du texte plutôt que planifier, le testeur d’expressions régulières est juste à côté.
Questions sur cron
Pourquoi mon travail s'exécute-t-il les jours que je n'ai pas planifiés ?
Presque certainement la règle du jour du mois et du jour de la semaine. Lorsque les deux champs sont restreints, cron exécute la tâche lorsque SOIT correspond – pas les deux. Ainsi, 0 0 1 * MON se déclenche le premier de chaque mois et chaque lundi, soit environ cinq fois par mois au lieu de la fois souhaitée. Si l’un des champs est *, la règle ne s’applique pas et l’autre prévaut simplement. Pour exiger les deux conditions, limitez un champ dans cron et vérifiez l'autre dans le travail.
Que signifient les cinq champs ?
Minute (0 à 59), heure (0 à 23), jour du mois (1 à 31), mois (1 à 12), jour de la semaine (0 à 7, où 0 et 7 signifient dimanche). La lecture de gauche à droite devient progressivement plus grossière, ce qui constitue un mnémonique utile. Certains planificateurs (Quartz, Spring et plusieurs exécuteurs de tâches) ajoutent un sixième champ pendant quelques secondes ; la crontab standard n'a aucun champ de secondes.
Qu'arrive-t-il à une tâche cron à l'heure d'été ?
Cela dépend de la mise en œuvre, et c'est là que les tâches planifiées s'interrompent discrètement deux fois par an. Lorsque les horloges avancent, une heure n'existe pas — une tâche de 02h30 peut être entièrement ignorée ou exécutée à 03h30, selon le cron. Lorsque les horloges reviennent, 01h30 se produit deux fois, le travail peut donc être exécuté deux fois. Les minuteries cron et systemd modernes de Vixie essaient d'être raisonnables à ce sujet ; les plus âgés ne le font pas. La réponse robuste consiste à exécuter le travail planifié en UTC et à effectuer la conversion en périphérie.
Que sont L, W et # et pourquoi sont-ils rejetés ici ?
Ce sont des extensions Quartz — L pour « dernier » (dernier jour du mois, vendredi dernier), W pour le jour de la semaine le plus proche et # pour « le nième jour de la semaine du mois ». Ils sont vraiment utiles et ne sont pas des cron standard. crontab, Kubernetes CronJobs et GitHub Actions les rejetteront ou les liront mal. Cet analyseur refuse plutôt que de deviner, car un planning qui ignore silencieusement un L serait erroné, exactement comme personne ne le vérifie.
Que fait @reboot ?
Il exécute le travail une fois au démarrage de cron, généralement au démarrage. Il n'a pas de planification récurrente, il n'y a donc pas de prochaines heures d'exécution à calculer — c'est pourquoi cet outil le dit au lieu d'afficher une liste vide. Il convient de savoir que @reboot se déclenche lorsque le démon cron démarre, et non lorsque la machine termine de démarrer, donc tout ce qui dépend de la disponibilité du réseau nécessite sa propre attente.
Comment exécuter quelque chose toutes les 90 minutes ?
Vous ne pouvez pas l’exprimer directement, et c’est une véritable limitation plutôt qu’une astuce que vous n’avez pas apprise. Les champs Cron sont indépendants, donc */90 dans le champ des minutes n'est pas valide et il n'y a aucun moyen de créer un planning qui ne se divise pas uniformément en une heure ou un jour. Les solutions de contournement consistent en deux entrées couvrant le modèle sur une journée ou, plus honnêtement, en un planificateur de tâches qui réfléchit en intervalles plutôt qu'en champs de calendrier, comme un minuteur systemd avec OnUnitActiveSec.
Dernière vérification . Vous avez repéré quelque chose de dépassé ? Dites-le-nous.