La syntaxe cron est constituée de cinq champs de nombres et de symboles qui doivent d'une manière ou d'une autre exprimer « chaque jour de semaine à 9 h sauf les jours fériés » ou « toutes les 15 minutes entre 8 h et 18 h ». Les champs sont minute, heure, jour du mois, mois et jour de la semaine, dans un ordre que personne ne retient correctement du premier coup, et les astérisques, virgules, tirets et barres obliques signifient tous des choses différentes selon leur position.
0 9 * * 1-5 paraît raisonnable, mais est-ce 9 h du matin ou 9 h du soir, et est-ce que 1-5 signifie du lundi au vendredi ou tout autre chose selon que l'implémentation cron compte dimanche comme 0 ou comme 7 ? Se tromper dans un pipeline de déploiement, une tâche de sauvegarde, ou un rapport planifié se traduit soit par des échecs silencieux, soit par une tâche qui se déclenche à une heure gênante — parfois pendant des semaines avant que quiconque ne le remarque.
Chaque implémentation cron a ses propres bizarreries
Le cron Unix standard, les CronJobs Kubernetes, AWS EventBridge, et diverses plateformes CI utilisent tous à peu près la même syntaxe à cinq champs mais diffèrent sur de petits points — la prise en charge des secondes, la manière dont la numérotation des jours de la semaine fonctionne, la validité de raccourcis comme @daily. Écrire une planification qui fonctionne correctement dès le premier déploiement exige de savoir précisément quelle variante de cron vous ciblez.
Traduire les expressions en langage clair
Bellows inclut un assistant d'expressions cron qui prend une chaîne de planification et explique ce qu'elle signifie réellement en langage clair, pour que vous puissiez vérifier votre intention avant de déployer une tâche planifiée où que ce soit.
Vérifier avant de déployer
Une tâche planifiée qui se déclenche au mauvais moment est souvent un échec silencieux — rien ne plante, elle s'exécute simplement quand vous ne le vouliez pas, parfois en se superposant à une fenêtre de maintenance ou en martelant une base de données pendant les heures de pointe. Vérifier la signification en langage clair d'une chaîne cron avant de fusionner une configuration de déploiement permet d'éviter que cela ne devienne une alerte à 2 h du matin.
Lire la planification de quelqu'un d'autre
Hériter d'une base de code avec une douzaine de tâches cron existantes implique de comprendre ce que fait chacune avant de pouvoir en modifier une en toute sécurité en toute sécurité. Traduire rapidement chaque expression est plus rapide que d'analyser mentalement cinq champs cryptiques une tâche à la fois.