Utilisation

Saisissez une expression à cinq champs. L'outil valide chaque champ, indique lequel pose problème le cas échéant, et calcule les cinq prochaines exécutions.

Les cinq champs

┌───────────── minute (0-59)
│ ┌─────────── heure (0-23)
│ │ ┌───────── jour du mois (1-31)
│ │ │ ┌─────── mois (1-12 ou JAN-DEC)
│ │ │ │ ┌───── jour de la semaine (0-6 ou SUN-SAT, 0 = dimanche)
│ │ │ │ │
* * * * *

7 est accepté comme alias de dimanche, en plus de 0 : crontab(5) le documente explicitement.

Le piège du jour du mois et du jour de la semaine

C'est la source de bug des expressions cron. Quand les deux champs de jour sont restreints — ni l'un ni l'autre à * — cron déclenche dès que l'un des deux correspond, pas quand les deux correspondent.

0 0 1 * 1

On lit volontiers « le premier lundi du mois ». En réalité : tous les lundis, et en plus le 1er de chaque mois. Pour obtenir un premier lundi, il faut tester la date dans le script lui-même :

# le 1er lundi du mois : cron déclenche tous les lundis, le script filtre
0 0 * * 1 [ "$(date +%d)" -le 07 ] && /usr/local/bin/mon-script

Dès qu'un seul des deux champs est restreint, la règle redevient intuitive : 0 9 * * 1-5 signifie bien « à 9 h, du lundi au vendredi ».

Fuseau horaire

Cet outil interprète les champs en UTC, comme cron système, GitHub Actions et Vercel. Un ordonnanceur qui interprète en heure locale pose deux questions sans bonne réponse : au passage à l'heure d'été, une tâche à 02:30 n'existe pas ; au passage à l'heure d'hiver, elle existe deux fois.

D'où une règle simple : planifiez en UTC et convertissez à l'affichage. Une tâche à 9 h heure de Paris se planifie à 0 8 * * * l'hiver et 0 7 * * * l'été — ou, mieux, se planifie à une heure où le décalage n'a pas d'importance.

Expressions valides qui ne se déclenchent jamais

0 0 30 2 *

Le 30 février est syntaxiquement correct et n'arrivera jamais. L'outil le détecte et le dit, au lieu de chercher indéfiniment.

0 0 29 2 * est plus subtile : elle se déclenche, mais seulement les années bissextiles — donc une fois tous les quatre ans.

Vérifier un cron dans un projet

// GitHub Actions : les minutes exactes sont déconseillées, le planificateur
// est surchargé à :00 et peut décaler de plusieurs minutes
on:
  schedule:
    - cron: "17 3 * * *" // plutôt que "0 3 * * *"

Un cron GitHub Actions n'est pas garanti à la minute : c'est une file d'attente partagée. Pour une tâche qui doit vraiment partir à l'heure, il faut un ordonnanceur dédié.