Crontab Guru

Collez une expression cron et obtenez une explication champ par champ, en anglais clair, de ce qu’elle fait. Inutile de mémoriser l’ordre des champs ou de rechercher les plages : le guru passe en revue chacun des cinq champs (minute, heure, jour du mois, mois et jour de la semaine) et lit l’expression de gauche à droite. Utile pour vérifier une ligne de crontab avant de la déployer ou pour expliquer une ligne que vous avez héritée.

Comment utiliser le guru

  1. 1

    Collez l'expression

    Copiez n'importe quelle expression cron standard à 5 champs (par exemple `0 9 * * 1-5`) dans le champ de saisie.

  2. 2

    Demandez l'explication

    Cliquez sur Explain Cron et l'outil renvoie une description ligne par ligne de chaque champ : minute, heure, jour du mois, mois et jour de la semaine.

  3. 3

    Lisez la description

    L'explication est générée en anglais, par exemple "Minute: every 5 minutes" ou "Hour: from 9 through 17."

  4. 4

    Vérifiez avant de déployer

    Servez-vous de l'explication pour confirmer que le planning fait ce que vous voulez avant de le mettre dans votre crontab, votre configuration CI ou un manifeste Kubernetes.

Feuille de triche des 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 ; Dim = 0 ou 7)
 │ │ │ │ │
 * * * * *

Opérateurs dans les expressions cron

Opérateur Signification Exemple
* Chaque valeur * * * * *
, Liste de valeurs 0,15,30,45
- Plage 9-17
/ Pas (début/pas) */5, 0-30/5
L Dernier (jour du mois ou dernier jour de la semaine, Quartz) L, 5L
W Jour de semaine le plus proche 15W (Quartz)
# N-ième jour de la semaine du mois 1#3 (Quartz)
? Pas de valeur spécifique Quartz uniquement

L’ordre de lecture compte

0 */2 * * 1-5 se lit de gauche à droite comme : minute 0, toutes les 2 heures, n’importe quel jour du mois, n’importe quel mois, du lundi au vendredi. Par habitude, on lit parfois les champs de droite à gauche et on se trompe ; commencez toujours par la minute.

Le piège des “toutes les X minutes”

*/10 * * * * se déclenche aux minutes 0, 10, 20, 30, 40, 50, pas “toutes les 10 minutes à partir de la création de la tâche.” Les pas de cron mesurent toujours depuis le début de la plage du champ. Si vous déployez une tâche à 12:03, la première exécution est à 12:10, pas à 12:13.

Pour les tâches qui ont vraiment besoin de “N minutes après la dernière exécution,” utilisez un planificateur avec un minuteur persistant (minuteurs systemd avec OnUnitActiveSec, ou planification au niveau de l’application avec un horodatage de dernière exécution stocké).

Pièges de cron à connaître

  • Jour du mois + jour de la semaine tous deux définis : la plupart des implémentations de cron traitent cela comme un comportement OU, probablement pas ce que vous voulez.
  • Pas de 0 : */0 est invalide.
  • Plage qui se replie : 22-2 pour les heures ne fonctionne pas dans le cron classique ; utilisez 22-23,0-2.
  • 30 février : un planning comme 0 0 30 2 * ne se déclenche jamais.
  • Ambiguïté de l’heure d’été : les tâches planifiées entre 2 h et 3 h peuvent se déclencher deux fois ou zéro fois les jours de changement d’heure.

Cron vs planificateurs modernes

Le cron Unix est encore partout, mais pour tout ce qui est critique, vous voudrez probablement :

  • minuteurs systemd : rattraper les exécutions manquées, prendre en charge des décalages aléatoires, lire depuis des fichiers d’unité.
  • Kubernetes CronJob : déclaratif, réessais, conscient des fuseaux horaires en 1.25+.
  • Airflow / Prefect / Dagster : pour les tâches avec dépendances, réessais, backfills et observabilité.
  • Planification GitHub Actions : cron à 5 champs, UTC uniquement, intervalle minimum de 5 minutes, livraison au mieux.

Le cron lui-même est un excellent format, mais un mauvais planificateur pour les tâches qui ne doivent pas être manquées.

Questions fréquentes

Parce que le jour de la semaine 0 est le dimanche dans le cron standard (et 7 est aussi dimanche, ce qui soutient les deux conventions). Le lundi est 1. Quartz numérote les jours de la semaine de 1 à 7 avec dimanche = 1, ce qui trompe souvent ceux qui passent d’un dialecte à l’autre.

Le cron Unix classique fonctionne dans le fuseau horaire local du serveur, peu importe ce que dit /etc/timezone. Kubernetes CronJob, GitHub Actions et la plupart des planificateurs cloud fonctionnent par défaut en UTC. Confirmez toujours et, quand c’est possible, utilisez UTC pour éviter les surprises liées à l’heure d’été.

Le cron classique ne peut pas exprimer cela directement. Solution de contournement : exécutez chaque lundi et vérifiez la date dans le script : [ $(date +%d) -le 7 ] && ./job.sh. Quartz le prend en charge nativement avec 1#1.

Non. Chaque planning a besoin de sa propre ligne. Mais vous pouvez combiner plusieurs plannings sur une ligne avec des listes : 0 9,17 * * * s’exécute à 9 h et à 17 h. Pour les plannings qui ne peuvent pas s’exprimer en une seule ligne, ajoutez plusieurs lignes pointant vers la même commande.

Outils similaires