Exemples d'expression Cron: 30 horaires expliqués (avec des pièges)

Cron a planifié des tâches récurrentes sur les systèmes Unix depuis les années 1970, et sa syntaxe à cinq champs pilote désormais Kubernetes CronJobs, GitHub Actions, les planificateurs cloud tels que AWS EventBridge et Google Cloud Scheduler, les pipelines CI et d'innombrables bibliothèques de tâches. La syntaxe est assez compacte pour mémoriser, mais suffisamment subtile pour que la plupart des ingénieurs aient envoyé au moins un calendrier qui s'est exécuté au mauvais moment. Ce guide explique chaque domaine, puis énumère 30 expressions pratiques avec des notes sur les pièges.

Les cinq champs

┌───────────── minute (0–59)
│ ┌─────────── hour (0–23)
│ │ ┌───────── day of month (1–31)
│ │ │ ┌─────── month (1–12 or JAN–DEC)
│ │ │ │ ┌───── day of week (0–6 or SUN–SAT; 7 is also Sunday on most systems)
│ │ │ │ │
* * * * *

Chaque champ accepte:

• * chaque valeur.
• Un nombre 5 signifie exactement 5.
• Une liste 1,15 signifie 1 et 15.
• Une plage 9-17 signifie 9 à 17 inclusive.
• Une étape */15 signifie toutes les 15 valeurs à partir du minimum; 10-50/20 signifie 10, 30, 50.

Une tâche s'exécute lorsque l'heure courante correspond à tous les champs à l'exception d'une exception importante couverte ci-dessous. Collez n'importe quelle expression dans un [cron expression parser] ((/tools/cron-parser) pour voir une description en langage clair et les prochains temps d'exécution.

Chaque N minutes ou heures

1. * * * * * chaque minute.
2. */5 * * * * toutes les 5 minutes (à 00h00, 00h05, 00h10 ...).
3. */15 * * * * toutes les 15 minutes.
4. 0,30 * * * * toutes les demi-heures, à une heure et demie.
5. 7 * * * * toutes les heures à 7 minutes après. Choisir une minute imparfaite écarte la charge de l'heure la plus occupée.
6. 0 */2 * * * toutes les 2 heures, à 00h00, 0h00, 0h00 ...
7. 0 */6 * * * quatre fois par jour: 00:00, 06:00, 12:00, 18:00.
8. 15 8-18/2 * * * à 08:15, 10:15, 12:15, 14:15, 16:15 et 18:15.

Pitfall: les étapes redémarrent à chaque limite. */7 dans le champ de minutes tire à 00h00, 00h07 ... 00h56 puis à 00h00 de nouveau, donc l'écart sur l'heure est de 4 minutes, pas 7. Si vous avez besoin d'un véritable intervalle fixe qui ne divise pas 60, utilisez un planificateur qui prend en charge les intervalles ou faites vérifier le temps écoulé par le travail lui-même.

Calendrier quotidien

9. 0 0 * * * tous les jours à minuit.
10. 30 2 * * * tous les jours à 2h30, une fenêtre de secours classique.
11. 0 9,17 * * * à 9h et 17h tous les jours.
12. 0 12 * * * à midi.
13. 45 23 * * * à 23h45, juste avant minuit pour les rapports de fin de journée.

Pitfall: les emplois entre 01:00 et 03:00 heure locale peuvent être sautés ou effectués deux fois en période d'été. Si votre serveur utilise une zone avec l'heure du jour, planifiez les tâches critiques en dehors de cette fenêtre ou exécutez le serveur en UTC.

Journées ouvrables et week-ends

14. 0 9 * * 1-5 09h du lundi au vendredi.
15. */10 9-17 * * 1-5 toutes les 10 minutes pendant les heures d'ouverture en semaine (dernière course à 17h50).
16. 0 10 * * 6,0 10h le samedi et le dimanche.
17. 0 8 * * MON 08:00 chaque lundi. Les noms sont insensibles aux majuscules sur la plupart des implémentations.
18. 30 16 * * 5 Vendredi à 16h30.

Mensuel et annuel

19. 0 0 1 * * minuit le premier jour de chaque mois.
20. 0 6 15 * * 06:00 le 15 de chaque mois.
21. 0 0 1,15 * * le 1er et le 15e, commun à la paie.
22. 0 0 1 1 * minuit du 1er janvier.
23. 0 9 1 */3 * 09h00 le premier jour de chaque trimestre (janvier, avril, juillet, octobre).
24. 0 0 L * * le dernier jour du mois. Note: L est une extension prise en charge par Quartz, certains planificateurs cloud et quelques bibliothèques, mais pas par le cron classique Unix.
25. 0 22 28-31 * * combiné avec une vérification à l'intérieur du script ([ "$(date -d tomorrow +%d)" = "01" ]) une façon portable d'exécuter le dernier jour du mois avec cron standard.

Le jour du mois ou le jour de la semaine ?

26. 0 9 13 * 5 beaucoup de gens lisent ça comme "Vendredi 13". En cron classique, cela signifie "tous les 13 du mois et tous les vendredis". Lorsque les deux champs de jour sont restreints (pas plus que *), Vixie cron et ses descendants exécutent le travail lorsque l'un ou l'autre correspond.

Pour exécuter uniquement le vendredi 13, planifiez 0 9 13 * * et vérifiez le jour de la semaine dans le script, ou utilisez un planificateur avec une sémantique explicite AND. C'est la règle la plus surprenante dans cron et qui vaut la peine d'être rappelée.

Des cordes spéciales

Beaucoup d'implémentations cron acceptent les raccourcis:

27. @hourly est le même que 0 * * * *.
28. @daily ou @midnight 0 0 * * *.
29. @weekly — 0 0 * * 0.
30. @reboot une fois au démarrage (Unix cron uniquement; pas disponible dans Kubernetes ou GitHub Actions).

Différences de plateforme

• Kubernetes CronJobs utilise une syntaxe standard de cinq champs. Depuis Kubernetes 1.27 vous pouvez définir spec.timeZone: "Europe/Berlin"; sinon les horaires suivent la zone du gestionnaire de contrôle, qui est généralement UTC.
• ** Les horaires des actions GitHub** s'exécutent toujours en UTC, peuvent être retardés pendant les périodes de forte charge, et l'intervalle minimum est de 5 minutes. Évitez 0 * * * * si la précision compte; choisissez une minute impaire.
• AWS EventBridge utilise six champs (minute hour day-of-month month day-of-week year) et nécessite ? dans l'un des deux champs de jour.
• **Quartz (Java) ** et Spring utilisent six ou sept champs avec des secondes d'abord: 0 0 9 * * MON-FRI.
• Les chronomètres système utilisent une syntaxe différente et plus lisible (OnCalendar=Mon..Fri 09:00) et gèrent les sorties manquées avec Persistent=true.

Vérifiez toujours quel dialecte votre plateforme attend avant de copier une expression.

Fuseaux horaires

Cron évalue les expressions dans le fuseau horaire du planificateur. Un travail écrit sous le nom de 0 9 * * * par un développeur à Tokyo s'exécute à 09:00 UTC sur un serveur UTC 18:00 à Tokyo. Les recommandations:

• Exécutez des serveurs et des planificateurs en UTC et convertissez les heures locales prévues en UTC lors de l'écriture des horaires.
• Si une tâche doit respecter les horaires d'ouverture locaux à travers les changements d'heure de l'été, utilisez un planificateur prenant en charge les fuseaux horaires explicites.
• Enregistrez l'horodatage de chaque exécution en UTC voir le [Guide Unix de l'horodatage] ((/blog/unix-timestamp-expliqué) pour savoir pourquoi.

Renforcer les emplois

Le bon timing n'est que la moitié de la bataille:

• Évitez les chevauchements. Si une tâche peut être exécutée plus longtemps que son intervalle, utilisez un verrou (flock sur Unix, concurrencyPolicy: Forbid dans Kubernetes).
• Faire des emplois idempotents. Un emploi qui se déroule deux fois, par exemple après une nouvelle tentative ou un chevauchement à l'heure de l'après-midi, ne devrait pas facturer deux fois plus aux clients.
• ** Capture output.** Les courriels cron classiques sortent à l'utilisateur local, qui ne va généralement nulle part. Rediriger vers les journaux et alerter sur les pannes.
• Utilisez des chemins absolus. Cron s'exécute avec un environnement minimal et PATH; les scripts qui fonctionnent dans votre shell échouent souvent sous cron.
• Moniteur de silence. Un service de fréquence cardiaque qui vous alerte lorsqu'un emploi n'est pas enregistré détecte les horaires brisés qui, autrement, échoueraient silencieusement.

Résumé

Les cinq champs de Cron minute, heure, jour du mois, mois, jour de la semaine combinés à des listes, des plages et des étapes couvrent presque tous les horaires récurrents. Surveillez la règle OR lorsque les deux champs de jour sont définis, les étapes qui se réinitialisent aux limites, l'heure du jour vers 01:0003:00, et les dialectes de plateforme avec des champs supplémentaires. Vérifiez chaque expression avec un analyseur qui montre les prochaines exécutions avant de le déployer.