Générateur d’expressions cron — créer et expliquer des planifications cron
Créez une planification cron avec des menus ou collez-en une, lisez-la en langage clair et voyez les 10 prochaines exécutions dans votre fuseau et en UTC. Gratuit, dans le navigateur.
minute · heure · jour du mois · mois · jour de la semaine. Les noms (JAN, MON), les macros de type @daily et une ligne de crontab entière collée sont acceptés.
Utilise une plage ou un pas (1-5) ; modifiez-le dans le champ de l’expression, ou choisissez des valeurs ci-dessous pour le remplacer.
…
Cron lit la planification dans le fuseau horaire de la machine sur laquelle il tourne. Choisissez « UTC » pour GitHub Actions, Vercel, la plupart des runners de CI et des planificateurs cloud ; les deux colonnes montrent les mêmes instants.
Collez la sortie de crontab -l. Les commentaires et les lignes VAR=valeur sont ignorés.
| Exécution toutes les 5 minutes. /usr/local/bin/healthcheck.sh | |
| À 02:30. /usr/local/bin/backup.sh --full | |
| À 09:00, chaque jour de la semaine de lundi à vendredi. php /var/www/artisan reports:send | |
| À 00:00, dimanche. certbot renew --quiet |
| Interroger une API ou une file toutes les 10 minutes | |
| Toutes les 6 heures (00:00, 06:00, 12:00, 18:00) | |
| Sauvegarde nocturne à 02:30 | |
| Toutes les heures pendant les heures de bureau, en semaine | |
| Toutes les 30 minutes pendant les heures de bureau | |
| Chaque semaine, le dimanche à minuit (comme @weekly) | |
| Deux fois par mois : le 1er et le 15 à 08:00 | |
| Derniers jours du mois (vérifier dans le script que demain = le 1er) | |
| Fenêtre de maintenance le samedi à 03:00 | |
| Chaque trimestre, à 04:15 le 1er janvier, avril, juillet et octobre | |
| Vendredi OU le 13 (la règle du OU en action) | |
| Macro : une fois par jour à minuit |
Fonctionne entièrement dans votre navigateur. Rien de ce que vous saisissez n’est envoyé ni stocké. Parcourir tous les outils gratuits.
Un problème, ou quelque chose à améliorer ? Nous lisons chaque message et corrigeons vite.
Ce générateur d’expressions cron gratuit construit une planification cron à cinq champs à partir de menus déroulants et traduit n’importe quelle expression en langage clair, avec les dix prochaines exécutions listées dans votre fuseau horaire et en UTC. Collez une expression, une ligne de crontab ou une crontab entière : chaque planification est expliquée. Il comprend la syntaxe standard commune à crontab, GitHub Actions, Kubernetes CronJob, Vercel cron et la plupart des planificateurs : astérisques, listes, plages, pas, noms de mois et de jours, et macros de type @daily.
La syntaxe cron est compacte et impitoyable : « 0 0 1 * * » et « 0 0 * * 1 » se ressemblent, mais signifient le premier de chaque mois d’un côté et chaque lundi de l’autre. Voir la planification en mots et sous forme de dates concrètes fait toute la différence entre une tâche qui tourne à 9 h en semaine et une qui tourne à 9 h UTC le dimanche — l’erreur que cette page existe pour éviter. Le calculateur suit exactement Vixie cron, y compris sa bizarrerie : un champ de jour qui commence par un astérisque change la façon dont les deux champs de jour se combinent. Il n’accepte pas la syntaxe Quartz (champ des secondes, L, W, #) et le signale quand vous la collez.
Mode d’emploi
- Partez d’un préréglage ou d’un exemple, ou saisissez ou collez une expression (une ligne de crontab complète est réduite à sa planification). La description en clair et les prochaines exécutions se mettent à jour pendant la saisie.
- Utilisez les cinq éditeurs de champ pour définir la minute, l’heure, le jour du mois, le mois et le jour de la semaine : chaque, tous les N ou valeurs précises.
- Vérifiez les dix prochaines exécutions. Choisissez « UTC » si la tâche doit tourner sur un serveur ou un runner de CI, qui utilise presque toujours l’UTC ; chaque exécution est affichée dans votre fuseau et en UTC.
- Pour auditer un serveur existant, collez la sortie de crontab -l dans « Expliquer une crontab entière ».
- Copiez l’expression, ou copiez une ligne de crontab complète avec la description en commentaire.
- Collez-la dans crontab -e, dans un bloc schedule: de GitHub Actions, dans la spec d’un CronJob Kubernetes ou dans les réglages cron de votre plateforme.
Questions fréquentes
Que signifient les cinq champs ?
Dans l’ordre : minute (0–59), heure (0–23), jour du mois (1–31), mois (1–12 ou JAN–DEC), jour de la semaine (0–7 ou SUN–SAT, 0 et 7 désignant tous deux le dimanche). Un astérisque signifie toutes les valeurs ; 1-5 est une plage ; 1,15 est une liste ; */10 signifie une valeur sur dix.
Que se passe-t-il quand le jour du mois et le jour de la semaine sont tous deux définis ?
Le cron standard (Vixie) lance la tâche quand l’un ou l’autre correspond, pas les deux. « 0 0 13 * FRI » s’exécute le 13 de chaque mois et chaque vendredi, pas seulement le vendredi 13. Cette page suit cette règle. Une subtilité : si l’un des champs de jour commence par un astérisque (par exemple */2), Vixie cron le considère comme non restreint et exige que les deux correspondent ; « 0 0 */2 * 1 » désigne donc les jours impairs qui tombent un lundi. Quartz fonctionne différemment et utilise un ? pour marquer le champ inutilisé.
Quel fuseau horaire cron utilise-t-il ?
Celui de la machine ou du service qui l’exécute. Les serveurs personnels utilisent généralement l’heure locale ; les runners cloud, GitHub Actions, Vercel et la plupart des clusters Kubernetes utilisent l’UTC. Une tâche réglée sur 9 h sur un runner en UTC se déclenche à 5 h à Toronto en été et à 4 h en hiver. Le tableau des exécutions affiche chaque heure dans votre fuseau et en UTC, pour que le décalage soit visible.
Les secondes ou les extensions L, W et # sont-elles prises en charge ?
Non. La syntaxe à six champs (avec les secondes) et les extensions L (dernier), W (jour ouvré) et # (n-ième jour de la semaine) appartiennent à Quartz et à certains planificateurs d’entreprise, pas au cron standard, et la plupart des plateformes les refusent. Pour « le dernier vendredi du mois », l’approche portable consiste à lancer une tâche chaque vendredi qui vérifie elle-même la date.
Pourquoi ma tâche ne s’exécute-t-elle jamais ?
Causes fréquentes : la planification est valide mais impossible (31 avril, 30 février) ; le serveur est dans un autre fuseau horaire que celui que vous supposiez ; la ligne de crontab n’a pas de commande ou le PATH de la commande diffère de celui de votre shell ; ou l’intervalle est plus court que la durée de la tâche elle-même et les instances s’accumulent. La liste des prochaines exécutions détecte les deux premières.
Aide-mémoire de la syntaxe cron
• * toutes les valeurs · 5 exactement 5 · 1-5 plage · 1,3,5 liste · */15 une valeur sur 15 · 1-30/5 une valeur sur 5 de 1 à 30
• Noms : JAN–DEC pour les mois, SUN–SAT pour les jours de la semaine (insensibles à la casse) ; les plages de noms fonctionnent (MON-FRI).
• @hourly (0 * * * *), @daily ou @midnight (0 0 * * *), @weekly (0 0 * * 0), @monthly (0 0 1 * *), @yearly ou @annually (0 0 1 1 *) ; @reboot s’exécute une fois au démarrage. Crontab les accepte, mais pas toutes les plateformes ; la forme à cinq champs est la plus portable.
• Le jour de la semaine 0 et le 7 désignent tous deux le dimanche. Les plages ne bouclent pas : FRI-MON est une erreur ; écrivez FRI-SAT,SUN-MON ou 5,6,0,1.
• Les champs sont séparés par des espaces ; dans une crontab, la commande suit sur la même ligne.
Où placer les planifications cron
Linux et macOS : crontab -e, une tâche par ligne, l’expression puis la commande. GitHub Actions : on: schedule: - cron: '0 9 * * 1-5', toujours en UTC, et les exécutions peuvent être retardées de plusieurs minutes aux heures chargées. Kubernetes : le champ schedule d’un CronJob. Vercel : crons dans vercel.json avec un path et un schedule, en UTC. Les planificateurs cloud (AWS EventBridge, Google Cloud Scheduler) acceptent la même syntaxe avec de petites différences de dialecte, et EventBridge ajoute un champ année.
Comment les prochaines exécutions sont calculées
Le calculateur avance d’un jour calendaire à la fois à partir de maintenant. Pour chaque jour, il vérifie le mois, puis les champs jour du mois et jour de la semaine avec la règle de Vixie (OU quand les deux sont restreints, ET quand l’un commence par *), et seulement ensuite liste les heures et minutes correspondantes. Les exécutions qui ne sont pas strictement postérieures à la minute en cours sont ignorées : une tâche prévue à cette minute précise apparaît à sa prochaine occurrence.
Dans votre propre fuseau horaire, l’heure d’été compte. Une heure qui n’existe pas le jour où l’on avance les horloges (2 h 30 dans la majeure partie de l’Amérique du Nord) est sautée, et une heure qui se produit deux fois quand on recule les horloges ne s’exécute qu’une fois. C’est ainsi que cronie gère les tâches à heure fixe ; d’autres démons peuvent différer, raison de plus pour laquelle les serveurs font généralement tourner cron en UTC.
Une planification qui désigne une date impossible (30 février, 31 avril) ne se déclenche jamais, et la page le signale. Une planification au 29 février ne se déclenche que les années bissextiles ; la recherche porte sur les neuf années à venir, ce qui suffit pour toute planification réelle.
Outils gratuits similaires
- Testeur de regex — Testez une expression régulière sur un texte d’exemple avec surlignage des correspondances en direct, groupes de capture et aperçu du remplacement. Gratuit, dans votre navigateur.
- Formateur JSON — Indentez, minifiez et validez du JSON, avec les erreurs d’analyse localisées par ligne et colonne. Dans votre navigateur, sans envoi.
- Convertisseur d’unités — Convertissez instantanément toutes les unités courantes dans votre navigateur : métriques et impériales, cuisine, données, pression, énergie, vitesse, consommation de carburant.