Explicateur d'expressions cron, gratuit

Collez une expression cron et comprenez exactement ce qu'elle fait.

Exemples courants

Comment lire les expressions cron

Une expression cron standard a 5 champs séparés par des espaces :

minute heure jour mois jour-semaine

* · toute valeur   */n · toutes les n unités   1,5 · aux valeurs 1 et 5   1-5 · plage de 1 à 5

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

Comment ça marche

  1. Entrez une expression cron : collez une chaîne cron à 5 ou 6 champs comme 0 9 * * 1-5.
  2. Lisez l'explication en langage clair : l'outil affiche immédiatement une description lisible de quand la tâche s'exécute.
  3. Visualisez les prochaines exécutions : une liste des 5 à 10 prochaines exécutions planifiées est affichée à partir de la date et l'heure actuelles.
  4. Validez : les expressions invalides sont mises en évidence avec des messages d'erreur précis expliquant le problème.

Un demi-siècle de tics d’une minute

cron est le plus ancien planificateur encore en usage continu et quotidien sur la plupart des serveurs du monde. Sa première apparition dans les archives historiques remonte à mai 1975, quand une version précoce a été livrée par AT&T Bell Laboratories dans le cadre de la branche Research Unix. Le nom est un clin d’œil à Chronos, la personnification grecque du temps, et la conception a vieilli avec une grâce étrange : les mêmes cinq champs séparés par des espaces que les ingénieurs des Bell Labs tapaient dans /usr/lib/crontab au milieu des années 1970 pilotent encore les CronJobs Kubernetes, les schedules GitHub Actions et la sauvegarde nocturne de la base de données sur un serveur privé virtuel quelque part à Francfort en ce moment même. L’implémentation de 1975 était minimale, il y avait un seul crontab, possédé par root, qui servait toute la machine. Si un utilisateur voulait une tâche récurrente, il demandait à l’administrateur d’ajouter une ligne à la main. cron est passé dans le monde plus large avec Version 7 Unix, sortie en 1979. Robert Brown et Keith Williamson à l’Université Purdue ont étendu cron pour gérer plusieurs utilisateurs fin 1979, introduisant le flux crontab -e par utilisateur. La réécriture décisive est arrivée quand Paul Vixie a sorti vixie-cron 1.0 le 6 mai 1987 ; vixie-cron a formalisé les caractères spéciaux et introduit les raccourcis @reboot, @hourly, @daily, @weekly, @monthly, @yearly. Vixie 3.0 (27 décembre 1993) a ajouté les valeurs de pas (/) et a été intégré, avec des correctifs mineurs, dans presque toutes les distributions Linux et les BSD de l’époque. POSIX a rattrapé en 1992 (IEEE Std 1003.2-1992). Chaque bizarrerie de cron moderne (la numérotation décalée du dimanche, le bug d’union vs intersection des champs jour) est une cicatrice de cette évolution ; rien n’a été conçu en une seule fois.

Anatomie d’une expression à cinq champs

Une expression cron standard se compose de cinq champs séparés par des espaces. De gauche à droite, ils demandent : quelle minute, de quelle heure, de quel jour-du-mois, de quel mois, de quel jour-de-la-semaine ? Les plages exactes ne sont pas négociables en cron POSIX : minute 0-59, heure 0-23, jour-du-mois 1-31, mois 1-12, jour-de-la-semaine 0-7 avec à la fois 0 et 7 représentant dimanche. Chaque champ accepte cinq opérateurs qui se composent librement : * signifie toute valeur valide ; , sépare une liste de valeurs discrètes (0,15,30,45 * * * * s’exécute pile, à et quart, à et demie, et trois-quarts à chaque heure) ; - est une plage inclusive (9-17 dans le champ heure signifie 9, 10, 11, 12, 13, 14, 15, 16, 17) ; / est une valeur de pas (*/15 dans le champ minute signifie toutes les quinze minutes en partant de zéro, soit 0, 15, 30, 45). Les mois et jours de la semaine peuvent aussi s’écrire en abréviations de trois lettres : JAN-DEC et SUN-SAT. Un exemple détaillé : */15 9-17 * * 1-5 se lit toutes les quinze minutes pendant les heures 9 à 17 incluses, chaque jour du mois, chaque mois de l’année, du lundi au vendredi: « tous les quarts d’heure pendant les heures de bureau en semaine ».

Le piège jour-du-mois / jour-de-la-semaine

La bizarrerie cron la plus lourde de conséquences (celle qui a causé des pannes, des sauvegardes manquées et des cycles de facturation silencieusement faux en production depuis trente-cinq ans) est la façon dont cron combine les champs jour-du-mois et jour-de-la-semaine quand les deux sont restreints. La formulation POSIX est inhabituellement précise ici : « si à la fois le “jour du mois” (champ 3) et le “jour de la semaine” (champ 5) sont restreints (ne contiennent pas “*”), alors un ou les deux doivent correspondre au jour courant. » Autrement dit, quand aucun des deux champs n’est en wildcard, cron prend l’union des deux, la tâche s’exécute n’importe quel jour qui satisfait l’une ou l’autre restriction. C’est l’opposé de ce que la plupart des utilisateurs supposent. Lire 0 0 13 * 5 à voix haute (« minuit le 13, le vendredi ») sonne naturellement comme une intersection : seulement le vendredi 13. Dans vixie-cron et ses descendants, cela signifie en réalité « chaque 13 du mois et chaque vendredi », s’exécutant environ neuf fois par mois. Pire, vixie-cron décide d’utiliser l’union ou l’intersection en n’inspectant que le premier caractère de chaque champ jour. Paul Vixie lui-même a reconnu le comportement comme un bug, mais a refusé de le corriger, notant que le corriger violerait le principe de moindre surprise, des millions de crontab étaient déjà écrites en supposant que le comportement existant était délibéré. Le bug est donc maintenant une fonctionnalité, immortelle et auto-propagatrice. Le modèle mental pragmatique : si vous vous retrouvez à restreindre à la fois jour-du-mois et jour-de-la-semaine et que vous voulez vraiment l’intersection (p. ex. « le deuxième mardi de chaque mois »), utilisez l’opérateur # dans les implémentations qui le supportent (Quartz, cronie avec extensions) : 0 12 ? * 2#2. En cron POSIX pur, l’intersection est réellement impossible à exprimer dans une seule expression et vous devez filtrer à l’intérieur du script que cron invoque.

Les macros raccourcies

Ces raccourcis ne font pas partie de POSIX. Les environnements strictement POSIX rejetteront @daily ; en pratique, toute implémentation de cron qu’un lecteur est susceptible de rencontrer (vixie-cron, cronie, fcron, ISC cron, images de conteneurs) les supporte.

Les dialectes, standard vs Quartz vs AWS vs K8s vs systemd

L’« expression cron » est désormais une petite famille de dialectes mutuellement incompatibles. cron 5 champs standard (POSIX, vixie-cron, cronie) : minute heure jour-du-mois mois jour-de-la-semaine, le plus petit dénominateur commun universel. Quartz Scheduler (6 ou 7 champs, écosystème Java) : secondes minutes heures jour-du-mois mois jour-de-la-semaine [année] ; introduit ?, L (last), W (weekday), # (n-ième jour de la semaine du mois). Le @Scheduled de Spring et Spring Boot utilisent Quartz. Kubernetes CronJob utilise le cron 5 champs standard, avec un champ spec.timeZone séparé qui est passé GA dans K8s 1.27 (la ressource CronJob elle-même est devenue GA dans 1.21, en avril 2021) ; le format de fuseau horaire est la base IANA tz (Europe/Berlin, America/New_York). Les schedules cron de GitHub Actions utilisent le cron POSIX 5 champs et s’exécutent en UTC. Le cron d’AWS EventBridge utilise 6 champs (minutes heures jour-du-mois mois jour-de-la-semaine année), exige l’opérateur ? sur le jour-du-mois ou le jour-de-la-semaine (vous ne pouvez pas restreindre les deux), et utilise 1-7 avec SUN=1, ce qui veut dire qu’une expression EventBridge 0 12 ? * 2 * s’exécute à midi le lundi, pas le mardi. Les timers systemd utilisent une syntaxe entièrement différente (OnCalendar=*-*-* 02:00:00) et remplacent progressivement cron sur Linux moderne pour la planification système, bien que les deux soient livrés côte à côte sur chaque distribution majeure. Cloud Scheduler (Google Cloud) utilise le cron 5 champs standard avec configuration explicite du fuseau horaire. Traduire des expressions entre plateformes demande une attention soigneuse : un schedule EventBridge copié-collé s’exécutera le mauvais jour de la semaine dans vixie-cron à cause du décalage de numérotation des jours.

Patrons courants à mémoriser

Pièges courants

Fuseau horaire. cron utilise par défaut l’heure locale du système, surprenant sur les machines cloud qui sont par défaut en UTC. Une tâche cron à 9 h sur un serveur UTC se déclenche à 4 h heure de New York. Les planificateurs modernes (Kubernetes 1.27+, AWS EventBridge, Cloud Scheduler) ont ajouté des champs de fuseau explicites ; le cron classique non. La règle « */N commence à 0 ». */15 donne 0, 15, 30, 45, pas 5, 20, 35, 50. Pour démarrer à un offset non nul, vous devez énumérer (5,20,35,50) ou utiliser la syntaxe Quartz-only 5/15. Le piège d’empilement de 60 minutes. Une tâche qui dure plus longtemps que son intervalle de planification peut s’empiler, trois sauvegardes de 30 minutes lancées toutes les 15 minutes vont se chevaucher. La parade standard est flock(1) : * * * * * /usr/bin/flock -n /tmp/myjob.lock /path/to/myjob garantit qu’une seule instance s’exécute à la fois ; le drapeau -n rend l’acquisition du verrou non bloquante, donc les invocations suivantes se terminent silencieusement au lieu de se mettre en file. Anomalies d’heure d’été. Une tâche cron prévue pour 02:30 se déclenchera deux fois le jour où l’horloge recule et pas du tout le jour où elle avance. cron n’a pas la notion « d’heure de l’horloge en tenant compte de l’heure d’été » ; si votre planning doit éviter les transitions DST, ancrez-le à une heure non affectée (3 h ou plus tard dans la plupart des fuseaux) ou utilisez un planificateur qui comprend les sémantiques de fuseau. Suppression du PATH. Les tâches cron s’exécutent avec un PATH minimal (/usr/bin:/bin) et un environnement quasi vide ; les scripts qui marchent dans votre shell interactif peuvent échouer dans cron parce que node, python3 ou aws ne sont pas sur le PATH hérité. Soit vous définissez PATH= en haut du crontab, soit vous utilisez des chemins absolus dans la commande cron. Débordement de courrier. Par défaut, cron envoie la sortie de chaque tâche à la boîte aux lettres locale de l’utilisateur ; sur un serveur sans configuration mail, cela remplit silencieusement /var/spool/mail jusqu’à ce que le disque soit plein. Soit vous redirigez la sortie (>/dev/null 2>&1), soit vous mettez MAILTO="" en haut du crontab, soit vous configurez réellement un transfert de courrier.

Alternatives modernes, quand viser autre chose

cron est excellent pour les tâches récurrentes simples sur une seule machine. Il est mauvais à : la planification distribuée (la même tâche déclenchée une seule fois sur une flotte plutôt qu’une fois par machine), les déclencheurs événementiels (s’exécuter quand une file de messages reçoit un message, pas sur une horloge), la supervision (cron échoue silencieusement si la tâche sort avec un code différent de zéro, sauf si vous configurez le transfert d’e-mail), les nouvelles tentatives (aucun mécanisme intégré, les tâches échouées ré-exécutent au cycle suivant et accumulent de l’état), et les dépendances (exécuter la tâche B seulement après que la tâche A ait réussi). Pour ces cas, la réponse moderne est l’une de : Kubernetes CronJob (planification orientée cluster avec politiques de retry et de parallélisme), AWS EventBridge + Lambda ou Step Functions (événementiel avec observabilité intégrée), Apache Airflow ou Prefect (orchestration de workflows DAG avec dépendances explicites), Temporal (exécution de workflows durables), healthchecks.io (un « interrupteur d’homme mort » qui vous prévient quand une tâche cron ne se lance pas à l’heure prévue). Pour les tâches récurrentes sur une seule machine en 2026, le simple cron reste la bonne réponse ; pour tout le reste, l’une des alternatives vaut la configuration supplémentaire.

Questions fréquentes

Que signifie * dans une expression cron ?

Un astérisque (*) dans un champ cron signifie « toute valeur valide », chaque minute, chaque heure, chaque jour, chaque mois, chaque jour-de-la-semaine. * * * * * s’exécute chaque minute de chaque jour. L’astérisque est aussi spécial dans les champs jour-du-mois et jour-de-la-semaine à cause du piège union vs intersection : quand l’un des deux champs jour a un * de tête, vixie-cron utilise le mode intersection ; quand aucun ne l’a, il utilise le mode union et exécute sur l’union des deux restrictions.

Comment exécuter une tâche cron toutes les 15 minutes ?

Utilisez la notation de pas : */15 * * * * s’exécute toutes les 15 minutes, à xx:00, xx:15, xx:30 et xx:45. Notez que */N commence toujours à 0 ; vous ne pouvez pas utiliser */15 pour dire « toutes les 15 minutes en partant de la minute 5 », pour cela vous écririez 5,20,35,50 * * * *. Le cron en dialecte Quartz supporte 5/15 comme alternative non standard.

Quelle est la différence entre cron et at ?

cron exécute des tâches sur un planning répétitif (chaque minute, chaque jour, chaque semaine). La commande at planifie une tâche unique pour s’exécuter à un moment futur précis, at 14:30 tomorrow met une tâche en file pour ce seul instant. Utilisez cron pour les tâches récurrentes et at pour les exécutions futures uniques. Les deux descendent de la même lignée Bell Labs / vixie-cron et ont fini par être intégrés au même démon sur la plupart des systèmes.

Pourquoi ma tâche cron ne correspond-elle pas à ce que je voulais ?

Cinq causes les plus fréquentes, par ordre approximatif de fréquence : (1) Confusion jour-du-mois vs jour-de-la-semaine (cron utilise l’union des deux quand les deux sont restreints, pas l’intersection. (2) Fuseau horaire) cron utilise par défaut l’heure locale du serveur, souvent UTC sur les machines cloud. (3) Problèmes de PATH, le PATH de votre shell interactif n’est pas hérité, donc des commandes qui marchent à l’invite peuvent échouer dans cron. (4) Le piège */N qui commence toujours à 0. (5) Sortie qui n’est capturée nulle part, les tâches échouées disparaissent silencieusement si vous n’avez pas configuré l’e-mail ou redirigé la sortie vers un fichier de log. Le panneau « 10 prochaines exécutions planifiées » de cet outil est la manière la plus économique de vérifier ce que votre expression signifie réellement avant de déployer.

Cet outil supporte-t-il les formats cron non standard ?

Il gère le cron POSIX/vixie-cron à 5 champs standard, la variante Quartz/Spring à 6 champs avec secondes, et les chaînes spéciales @hourly, @daily, @weekly, @monthly, @yearly et @reboot. Il ne gère pas les extensions Quartz complètes (L, W, #) ni la numérotation des jours en base 1 d’AWS EventBridge, pour celles-ci, utilisez le validateur de la plateforme avant le déploiement.

Mon expression cron est-elle envoyée quelque part ?

Non. L’analyse et l’explication tournent entièrement dans votre navigateur via JavaScript. Les expressions collées ne traversent jamais le réseau, vérifiez dans l’onglet Réseau des DevTools pendant que vous cliquez sur Expliquer. Sûr pour les expressions cron dans des configurations CI de production, du code d’infrastructure et des runbooks opérationnels où le planning lui-même peut être sensible (p. ex. des schedules d’export nocturne de base de données qui indiquent les fenêtres de maintenance).

Outils associés

Générateur cron

Construisez des plannings cron visuellement avec préréglages, descriptions et prochaines exécutions.

Convertisseur epoch

Convertissez des timestamps Unix en dates humaines et inversement. Horloge epoch en direct.

Bibliothèque regex

Parcourez et copiez des motifs regex testés pour des tâches courantes.