Générateur d'expression cron

Les expressions cron sont de courtes chaînes aux lourdes conséquences

Une seule petite ligne déclenche tes sauvegardes. Tes rapports, tes jobs de nettoyage, les queue workers, les déploiements, tout ça repose sur cinq minuscules champs. La syntaxe est assez dense pour qu'une coquille passe complètement inaperçue. La timezone du serveur n'est peut-être pas celle que tu as en tête. Le day-of-month et le day-of-week ne se combinent pas comme la plupart des gens l'imaginent. Et certaines plateformes ajoutent un champ de secondes dont le cron Unix classique n'a jamais entendu parler. J'ai déjà vu un planning qui « avait l'air OK » partir quelques centaines de fois de plus que prévu. Personne n'a apprécié cette matinée-là.

J'ai construit cet outil pour qu'il soit le contrôle que je fais systématiquement avant de faire confiance à un planning. Il décompose chaque champ. Il dit tout haut ce que le job va réellement faire, aligne les prochaines exécutions, et signale là où une plateforme donnée pourrait lire ta syntaxe différemment. Cron simple à cinq champs, version à six champs avec secondes : il gère les deux. Et il te fera un petit signe sur les pièges habituels avant que tu colles quoi que ce soit dans un serveur, un container Docker, un CronJob Kubernetes, un workflow GitHub ou l'outil d'automatisation que tu utilises ce jour-là.

Comment lire un planning cron

Lis de gauche à droite : minute, heure, jour du mois, mois, jour de la semaine. Six champs ? Alors les secondes se glissent en tête. Une étoile signifie « toutes les valeurs autorisées ici ». Les virgules listent quelques valeurs précises. Le tiret, c'est une plage. Le slash, c'est un step. Honnêtement, les symboles ne sont pas le plus dur, tu les auras assimilés en un après-midi. Ce qui te piège, c'est de t'assurer que l'expression veut dire la même chose pour le scheduler qui va vraiment l'exécuter.

• Cron à cinq champs est la forme que tu croiseras le plus souvent sous Unix : minute heure jour mois jour-de-semaine.
• Cron à six champs glisse simplement les secondes devant les minutes.
• La syntaxe Quartz ajoute des tokens en plus comme ?, L, W ou # que le cron classique n'a jamais eus.
• La timezone vit avec le scheduler sur la plupart des systèmes, pas à l'intérieur de la chaîne. Ne suppose pas que l'expression la transporte, parce que la plupart du temps non.
• L'aperçu des prochaines exécutions reste, honnêtement, le moyen le plus rapide de repérer un planning discrètement faux avant qu'il ne parte en prod.

Exemples courants de débogage cron

Le job s'est lancé à la mauvaise heure ? Ne touche pas encore à l'expression. Vérifie d'abord la timezone du scheduler, parce que la plupart du temps c'est le coupable. Ça tourne bien trop souvent ? Regarde tes step fields, ceux du genre */5. La plateforme te recrache l'expression ? Détermine si elle veut cinq champs, six, ou du Quartz complet. Et si tu as fixé à la fois le day-of-month et le day-of-week, va découvrir si ton scheduler lit ça comme un OR ou comme un AND strict. Cette seule différence m'a déjà bouffé plus d'un week-end.

Questions fréquentes

Que signifient les cinq champs de cron ?

De gauche à droite : minute, heure, jour du mois, mois, jour de la semaine. Mets une astérisque dans n'importe lequel et tu dis « toutes les valeurs ici ». Donc une étoile dans le champ minute signifie chaque minute. Une fois que cet ordre est dans tes réflexes, lire une ligne de cron n'a plus rien d'intimidant.

Comment lancer un job tous les jours à minuit ?

0 0 * * * fait l'affaire. Minute 0 de l'heure 0, tous les jours. Colle-le tout en haut et je te le détaille, puis je te montre les prochains minuits qu'il va réellement viser. Comme ça tu sais qu'il atterrit là où tu crois avant qu'il n'approche de la prod.

Questions fréquentes

Est-ce que tous les systèmes cron supportent les secondes ?

Non. Celle-là, elle piège les gens en permanence. Le cron Unix classique s'arrête à cinq champs. Pas de secondes, point final. Certains schedulers plus récents ajoutent bien un champ de secondes, et les systèmes façon Quartz empilent encore plus de syntaxe par-dessus. Donc avant d'écrire cette ligne à six champs, assure-toi que ce qui va l'exécuter parle vraiment six champs.

Quelle timezone utilise cron ?

Celle dans laquelle le serveur ou le scheduler est configuré. Pas celle de ton portable. Et généralement pas UTC non plus, sauf si quelqu'un l'a décidé. Une poignée de plateformes hébergées te laissent définir une timezone par job, ce qui est génial quand tu l'as et un piège bien tranchant le jour où tu oublies que tu ne l'as pas. Dans le doute, logue la date tout en haut du job et relis-la.

Est-ce que cette preview peut remplacer les tests en production ?

Non, et ça m'embêterait que tu le croies. Il attrape vite les bourdes évidentes. Mais la vraie source de vérité, c'est le scheduler qui exécute réellement ton job, point final. Sers-toi de cet outil pour éliminer les bêtises, puis va vérifier sur le système live avant de considérer que c'est bouclé.

Quelle est la différence entre */5 et 5 dans un champ cron ?

Facile à confondre. Résultats radicalement différents. */5 est un step, toutes les cinq unités, donc dans le champ minute ça donne 0, 5, 10, 15 et ainsi de suite sur toute l'heure. Le 5 tout seul est une valeur unique : il se déclenche une fois, exactement à 5. Donc l'un tourne douze fois par heure. L'autre une seule. Choisis le mauvais et ton job occasionnel cesse soudain de l'être.