Que fait vraiment cette expression cron ?

Le cron standard se lit de gauche à droite : minute, heure, jour du mois, mois, jour de la semaine. Certains ordonnanceurs — celui-ci compris — acceptent un champ secondes optionnel en tête, ce qui en fait six au total. Chaque champ accepte un nombre, une liste séparée par des virgules, un intervalle (1-5), un pas (*/15) ou une combinaison (10-50/10). Les champs mois et jour de la semaine acceptent aussi des noms : JAN-DEC et SUN-SAT (ou 0-7, où 0 et 7 désignent tous deux le dimanche).

* signifie « n'importe quelle valeur » pour ce champ — * * * * * se déclenche chaque minute. */15 signifie « une valeur sur 15 à partir du minimum du champ » — pour les minutes, cela donne :00, :15, :30, :45.

Le cron ordinaire — celui de votre crontab — compte 5 champs, avec un plancher d'une exécution par minute. Certains outils (celui-ci, ou node-cron par exemple) acceptent un sixième champ en tête pour les secondes, seul moyen d'exprimer « toutes les 10 secondes » en syntaxe cron. Les deux se confondent facilement : 0 30 2 * * * a l'air de vouloir dire 2 h 30, mais avec six champs le premier 0 est un nombre de secondes et le planning se déclenche en fait à 02:30:00 — ce qui, écrit en cron à 5 champs, donnerait 30 2 * * *. Mal compter les champs est de loin la façon la plus courante de planifier la bonne tâche à la mauvaise heure.

Les raccourcis @ — @hourly, @daily, @weekly, @monthly, @yearly (@annually et @midnight en sont des alias) — se développent en expressions cron standard fixes et se comportent à l'identique. @reboot est un cas à part ; voir plus bas.

0 0 13 * 5 se lit comme « le 13, si c'est un vendredi » — un vendredi 13. Il n'en est rien. Le cron standard traite le jour du mois et le jour de la semaine comme un OU dès que les deux champs sont restreints : la tâche se déclenche le 13 de chaque mois et tous les vendredis, soit cinq ou six exécutions par mois au lieu de l'unique que vous imaginiez.

Cela ne mord que lorsque les deux champs sont restreints en même temps. 0 0 13 * * (tous les 13, jour de la semaine laissé à *) veut exactement dire ce qu'il a l'air de dire, et 0 0 * * 5 (tous les vendredis) aussi. C'est la combinaison qui bascule silencieusement du ET au OU, et c'est l'une des plus vieilles surprises de cron — POSIX le spécifie, toutes les implémentations majeures s'y conforment, et elle continue de piéger des gens qui ont appris à programmer bien après la plupart des specs POSIX.

Cron planifie en heure locale, et l'heure locale n'est pas continue lors d'un changement d'heure. Deux fois par an, quelque part, une horloge saute une heure ou en répète une — et une tâche planifiée à l'intérieur de cette heure doit bien faire quelque chose, puisque « exécute-la quand même » n'a aucun sens univoque.

Au passage à l'heure d'été, les heures locales sautées n'existent tout simplement pas. Une tâche réglée à 02:30 le jour où Europe/Paris passe de 02:00 à 03:00 n'a pas de 02:30 où s'exécuter — cet outil signale alors l'exécution comme sautée plutôt que de la déplacer discrètement à 01:30 ou 03:30, parce que l'une comme l'autre de ces suppositions serait fausse au moins aussi souvent que juste.

Au retour à l'heure d'hiver, les heures locales répétées surviennent deux fois. Cet outil suit la convention de toutes les implémentations de cron que nous connaissons : se déclencher une seule fois, à la première occurrence, et non deux.

Le correctif pratique est ennuyeux mais fiable : planifiez vos tâches de maintenance hors de la plage 00:00-04:00, où la plupart des régions placent leur changement d'heure, ou faites tourner votre infrastructure en UTC de bout en bout — auquel cas toute cette section ne vous concerne pas.

@reboot s'exécute une fois, au démarrage de la machine — cron lui-même ne garantit rien de plus, et n'a aucune notion de « prochaine exécution » pour lui, puisqu'il n'y en a pas. Cela en fait un mauvais candidat pour le schéma habituel de supervision, « préviens-moi si ça ne tourne pas à l'heure prévue » : il n'y a pas d'heure prévue, donc rien à quoi comparer un silence. Si une tâche @reboot compte — restaurer un état après un plantage, disons — ce qui mérite d'être supervisé est en général l'état qu'elle restaure, pas l'événement de démarrage.

Faut-il un compte ?

Non. Pas d'inscription, et pas de limite de débit qui vaille d'être mentionnée, puisque rien ici ne s'adresse à un serveur — l'analyse et le calcul des prochaines exécutions se font dans votre navigateur.

Conservez-vous les expressions que je teste ?

Non. Rien de ce que vous tapez n'est envoyé où que ce soit : il n'y a donc rien à conserver, ni rien que vous puissiez nous demander de supprimer.

Pourquoi affiche-t-il parfois moins de 8 exécutions ?

Quelques expressions décrivent un planning qui se déclenche rarement, voire jamais. 0 0 31 2 * (31 février) ne correspond à aucune date réelle et renvoie zéro exécution. 0 0 29 2 * (29 février) ne correspond qu'aux années bissextiles : il faut donc parfois chercher plusieurs années avant de voir apparaître la prochaine.

Quelles extensions cron ne sont pas prises en charge ?

Les extras à la Quartz que certains ordonnanceurs ajoutent au-dessus du cron POSIX : L (dernier jour), W (jour ouvré le plus proche), # (n-ième jour de la semaine du mois) et ? (pas de valeur particulière). Cet outil les signale explicitement plutôt que de les interpréter en silence comme autre chose.

Mon serveur utilise un autre fuseau que celui choisi ici — est-ce important ?

Oui, et cela vaut la peine de vérifier. Sur une machine Linux typique, cron tourne dans le fuseau configuré du système, pas forcément UTC et pas forcément le vôtre. Choisissez le fuseau dans lequel la crontab de votre tâche s'exécute vraiment, pas celui où vous vous trouvez, sinon les heures d'exécution affichées ici ne correspondront pas à la réalité.