PawaCron — Cron Expression Decoder

Pourquoi vérifier une expression cron ?

Cron est un outil simple, ancien et très fiable. C’est aussi pour cette raison qu’il est encore partout : sauvegardes, rotations de logs, synchronisations, scripts de maintenance, exports, traitements applicatifs ou tâches de supervision.

Mais une expression cron mal comprise peut déclencher une tâche trop souvent, trop rarement, au mauvais moment ou jamais. En exploitation, ce genre d’erreur est rarement spectaculaire au début. Elle se voit souvent plus tard : logs qui grossissent, scripts qui se chevauchent, sauvegardes manquantes, appels API excessifs, charge serveur inutile ou traitements qui tournent pendant les heures sensibles.

Comment lire une expression cron standard

Une expression cron standard contient cinq champs :

minute hour day-of-month month day-of-week

Exemple :

*/15 9-18 * * 1-5

Cette expression signifie : toutes les 15 minutes, entre 09:00 et 18:59, du lundi au vendredi.

Exemples courants

Toutes les cinq minutes

*/5 * * * *

Cette planification peut être utile pour un job léger de monitoring. Elle devient risquée pour un script lourd, un export, une sauvegarde ou un traitement qui peut durer plus de quelques minutes.

Tous les jours à 02:30

30 2 * * *

Ce format est classique pour des tâches nocturnes. Il faut tout de même vérifier que plusieurs jobs lourds ne démarrent pas tous à la même heure.

Chaque lundi à 03:00

0 3 * * 1

Format fréquent pour des rapports hebdomadaires, nettoyages ou traitements planifiés.

Le piège du chevauchement

Une expression cron peut être parfaitement valide et rester dangereuse. Le cas le plus classique est une tâche qui s’exécute plus souvent qu’elle ne se termine.

Exemple : un script lancé toutes les minutes mais qui met parfois trois minutes à finir. Sans verrou, plusieurs instances peuvent tourner en parallèle.

Une protection simple consiste à utiliser flock :

* * * * * flock -n /tmp/my-job.lock /usr/local/bin/my-job.sh

Cela empêche une nouvelle exécution de démarrer si la précédente est encore active.

Bonnes pratiques avant mise en production

• Tester la commande manuellement avant de la planifier.
• Utiliser des chemins absolus.
• Vérifier l’utilisateur qui exécute la tâche.
• Rediriger correctement la sortie standard et les erreurs.
• Ajouter des logs exploitables.
• Prévoir un verrou si la tâche ne doit pas se chevaucher.
• Documenter la fréquence et l’objectif du job.

Position d’admin systèmes

Le bon réflexe n’est pas seulement de demander si une expression cron est valide. La vraie question est : cette tâche peut-elle tourner à cette fréquence, avec cette durée, sur cette machine, sans effet secondaire ?

PawaCron aide à lever l’ambiguïté sur la syntaxe et la fréquence. Le jugement opérationnel reste essentiel.

PawaCron helps remove ambiguity around cron syntax and frequency. Operational judgment still matters.