Résumé

Ce générateur d'expression cron prend une description de planification ou une chaîne cron collée, et l'évalue en une expression validée à 5 champs : minute, heure, jour du mois, mois, jour de la semaine. Choisissez un preset courant comme toutes les 5 minutes ou en semaine à 9h UTC, ou éditez chaque champ directement avec support des ranges, listes et valeurs pas-à-pas. L'outil affiche une description en français lisible de la planification et calcule les 5 prochaines exécutions en UTC, en utilisant la même logique OR des champs day-of-month et day-of-week que vixie-cron et Kubernetes CronJob utilisent, donc ce que tu vois ici correspond à ce qui tire réellement en production.

Générateur d'Expression Cron pour Jobs Programmés et Fenêtres de Déploiement

Construisez une expression cron à 5 champs à partir de presets, ou collez-en une pour la valider. Obtenez une description en français clair et les cinq prochaines exécutions avant de shipper cette planification.

Créer une planification

Générateur d'expression cron

Choisis des champs ou un preset ci-dessous. L'expression, la description en français clair et les 5 prochaines exécutions se mettent à jour à chaque lettre tapée.

Planifications courantes
0 9 * * 1-5

Sous le capot

Comment fonctionne ce générateur d'expression cron

Cinq champs, syntaxe standard

Minute, heure, jour du mois, mois et jour de la semaine : les mêmes champs que crontab, GitHub Actions schedule et Kubernetes CronJob lisent. Les ranges (9-17), listes (1,15,30), steps (*/5) et wildcards se parsent exactement comme en production.

Les champs jour sont en OR, pas AND

Définis jour du mois à 1 et jour de la semaine à lundi, et le job s'exécute le 1er du mois ou n'importe quel lundi, pas uniquement quand les deux concordent. C'est comme vixie-cron et Kubernetes CronJob l'évaluent vraiment, et c'est le détail que la plupart des générateurs oublient.

Cinq prochaines exécutions, calculées en direct

Chaque modification recalcule cinq timestamps UTC en avançant dans le vrai calendrier, donc une planification qui ne peut jamais s'exécuter, comme le jour 30 en février, s'affiche vide ici au lieu de rester silencieusement morte dans une crontab.

Colle pour vérifier, pas juste pour construire

Tu as déjà une chaîne cron d'un coéquipier, d'un manifeste CronJob, ou d'une vieille réponse Stack Overflow ? Colle-la dans le champ et obtiens la même description et les mêmes exécutions, aucun validateur séparé requis.

Comment l'utiliser

Des champs vides à une planification en laquelle tu as confiance

  1. 1

    Commence par un preset

    Choisis une planification courante (chaque 5 minutes, en semaine à 9h UTC, mensuel le 1er), ou garde les defaults et ajuste à partir de là.

  2. 2

    Ajuste les champs qui comptent

    Utilise les dropdowns de sélection rapide ou tape directement : les listes de virgules, les tirets pour les ranges et */N pour les steps fonctionnent dans chaque champ.

  3. 3

    Confirme avant de shipper

    Lis la description en français clair et contrôle les 5 prochaines exécutions contre ta fenêtre de maintenance ou ton SLO budget, puis copie l'expression dans ta crontab, ton CI schedule ou ton manifeste CronJob.

Détail de l'implémentation

Pourquoi les champs day-of-month et day-of-week utilisent la logique OR

POSIX/vixie-cron, l'implémentation derrière crontab Linux et Kubernetes CronJob, a une règle bizarre que presque personne ne lit plus loin. Si les deux champs day-of-month et day-of-week sont restreints loin du *, le job s'exécute quand l'un ou l'autre correspond, pas uniquement quand les deux le font. Définis day-of-month à 1 et day-of-week à lundi, et la planification tire le 1er du mois et n'importe quel lundi, pas uniquement un lundi qui arrive à être le 1er. Laisse l'un des deux champs comme *, et seul celui restreint limite le jour. Ce générateur suit cette convention parce que c'est ce qui tire réellement ta crontab, pas une version simplifiée d'elle. C'est surtout important pour le genre de planification qu'une équipe platform écrit à 23h : exécute ça le premier jour ouvrable ou le 1er du mois, celui qui vient en premier, ressemble à un AND pour la plupart des gens et fonctionne comme un OR en production.

  • POSIX/vixie-cron (crontab Linux, Kubernetes CronJob) : OR une fois l'un des champs jour restreint
  • Quartz cron (courant dans les scheduleurs Java) : en général requiert l'un des deux champs jour de rester ? au lieu de *, évitant complètement l'ambiguïté
  • Ce générateur suit la convention POSIX/vixie-cron, puisque c'est ce que crontab et CronJob exécutent réellement
Gros plan de la face d'une horloge analogique avec des engrenages devant un baie de serveurs floue

Questions courantes

Ce générateur d'expression cron est-il gratuit ?
Oui. Il fonctionne entièrement dans ton navigateur, pas de compte, pas de limite de débit, et aucune donnée envoyée nulle part sauf une balise de page-view anonyme.
Dans quel fuseau horaire les prochaines exécutions sont-elles affichées ?
UTC. La plupart des crontabs, GitHub Actions schedules et Kubernetes CronJob resources utilisent par défaut UTC ou l'heure système du conteneur, donc ça évite une erreur de conversion de fuseau horaire. Confirme ton propre fuseau horaire du système avant de compter sur la minute exacte.
Pourquoi day-of-month 1 et day-of-week lundi s'exécutent les deux, pas juste quand ils se chevauchent ?
Parce que c'est comme cron se comporte. Les implémentations standard vixie-cron, y compris crontab Linux et Kubernetes CronJob, évaluent ces deux champs avec la logique OR une fois l'un d'eux restreint loin du *. Cet outil correspond à ce comportement exprès.
Supporte-t-il @daily, @reboot ou d'autres macros de raccourci ?
Non, uniquement les cinq champs numériques standard, puisque c'est ce que la plupart des orchestrateurs exigent de toute façon. @daily mappe à 0 0 * * *, @hourly à 0 * * * *, et @weekly à 0 0 * * 0.
Ma planification est-elle envoyée à un serveur ?
Non. Le parsing, la description en français clair et le calcul des prochaines exécutions s'exécutent côté client. Rien sur les champs que tu tapes n'est transmis ou stocké.
Le calcul des prochaines exécutions prend-il en compte l'heure d'été ?
Non, tout est calculé en UTC, qui n'a pas d'heure d'été. Si le système exécutant ton daemon cron utilise l'heure locale avec heure d'été, contrôle le décalage séparément autour des dates de transition deux fois par an.
Puis-je taper des noms de mois ou de jour de la semaine au lieu de numéros ?
Oui. jan jusqu'à dec et dim jusqu'à sam fonctionnent dans les champs mois et jour-de-la-semaine aux côtés des ranges numériques 1-12 et 0-6, y compris dans les ranges et les listes.

Le cron job s'exécute. Qu'est-ce qui gate le déploiement qu'il déclenche ?

upstreamapi lie les rollouts de feature-flags à un budget SLO, donc un déploiement déclenché par cron peut auto-rollback avant que le pager ne se déclenche, pas après.

Vois comment les rollouts gâtés par SLO fonctionnent Retour au générateur