Data study
Expressions cron : quels plannings les développeurs utilisent-ils vraiment ?
'* * * * *' est l'expression cron la plus recherchée sur Google. C'est aussi celle qui risque le plus de mettre le feu à votre serveur.
By Buğra SözeriPublished
Cron est l’un des systèmes de planification les plus anciens encore en usage actif — le démon Unix cron original date de Version 7 Unix (1979) et la syntaxe à cinq champs est spécifiée dans POSIX.1 (IEEE Std 1003.1). Malgré des décennies d’alternatives (minuteries systemd, Kubernetes CronJobs, planificateurs cloud), l’expression cron à cinq champs reste la lingua franca des tâches planifiées.
Cette analyse agrège la fréquence des expressions cron à partir des questions Stack Overflow taguées “cron”, de la recherche de code GitHub sur les dépôts publics et des réponses aux sondages de développeurs. L’objectif est de documenter quels plannings les développeurs utilisent réellement en pratique — pas ce qui est documenté dans les manuels.
La syntaxe cron POSIX à cinq champs
Selon POSIX crontab(5), une expression cron a cinq champs :
┌───────────── minute (0–59)
│ ┌───────────── heure (0–23)
│ │ ┌───────────── jour du mois (1–31)
│ │ │ ┌───────────── mois (1–12)
│ │ │ │ ┌───────────── jour de la semaine (0–7, où 0 et 7 = dimanche)
│ │ │ │ │
* * * * *Un sixième champ (secondes) ne fait pas partie de la norme POSIX mais est pris en charge par de nombreux planificateurs modernes (Spring @Scheduled, Quartz, AWS EventBridge). Un septième champ (année) apparaît dans Quartz et certains planificateurs d’entreprise. Cette analyse couvre la syntaxe standard à cinq champs sauf indication contraire.
Les 20 motifs cron les plus courants
| Rang | Expression | Planning lisible | Cas d’usage typique | Prêt pour la production ? |
|---|---|---|---|---|
| 1 | * * * * * | Toutes les minutes | Tests, vérifications de pulsation, interrogation de files d’attente | Rarement — 1 440 exécutions/jour ; la plupart des tâches nécessitent des garanties d’idempotence |
| 2 | 0 * * * * | Toutes les heures, à :00 | Réchauffement du cache, agrégation de métriques, rapports horaires | Oui — cadence bien comprise, faible rayon de blast |
| 3 | 0 0 * * * | Quotidien à minuit (heure du serveur) | Sauvegardes quotidiennes de la base de données, tâches batch, scripts de nettoyage | Oui, avec réserve — minuit heure serveur ≠ minuit heure utilisateur ; le fuseau horaire doit être explicite |
| 4 | */5 * * * * | Toutes les 5 minutes | Vérifications de santé, interrogation courte de flux, files de réessai | Souvent — 288 exécutions/jour ; acceptable si chaque exécution est rapide et idempotente |
| 5 | */15 * * * * | Toutes les 15 minutes | Synchronisation de données, mises à jour des taux de change, lectures de capteurs | Oui — 96 exécutions/jour, cadence équilibrée |
| 6 | 0 9 * * 1-5 | Jours ouvrables à 09h00 | Notifications aux heures de bureau, rappels de réunion matinale | Oui — motif courant ; attention aux changements d’heure au printemps/automne |
| 7 | 0 0 1 * * | Premier jour de chaque mois à minuit | Facturation mensuelle, génération de factures, rotation des archives | Oui — faible fréquence ; vérifier les sémantiques fin de mois vs début de mois pour la facturation |
| 8 | 30 23 * * * | Quotidien à 23h30 | Rapports de fin de journée, traitements en lot de pré-minuit | Oui — choisir des moments hors pointe réduit la contention des ressources |
| 9 | 0 2 * * * | Quotidien à 02h00 | Maintenance fenêtre faible trafic, réindexation, vacuum | Oui — fenêtre faible trafic populaire dans les fuseaux US/EU |
| 10 | */30 * * * * | Toutes les 30 minutes | Nettoyage de sessions, invalidation de cache, rotation de journaux | Oui — 48 exécutions/jour, équilibre pratique |
| 11 | 0 0 * * 0 | Dimanches à minuit | Réindexation hebdomadaire, sauvegardes complètes, mises à jour de dépendances | Oui — le dimanche minuit est une fenêtre de maintenance conventionnelle |
| 12 | 0 12 * * * | Quotidien à midi | Rapports de mi-journée, fenêtres faible trafic de l’heure du déjeuner | Oui — noter que “midi” signifie des heures différentes dans différents fuseaux |
| 13 | 0 0 1 1 * | 1er janvier à minuit | Création d’archive annuelle, génération de rapport annuel | Oui — tâches une fois par an ; s’assurer que la tâche n’est pas déclenchée accidentellement en test |
| 14 | */10 * * * * | Toutes les 10 minutes | Drainage de file, interrogation d’APIs avec limites de taux, vérifications de statut | Souvent — 144 exécutions/jour ; vérifier que la tâche se termine en moins de 10 minutes |
| 15 | 0 6 * * 1 | Lundis à 06h00 | Newsletters hebdomadaires, résumés de début de semaine | Oui — motif courant de communication d’entreprise |
| 16 | 0 0 15 * * | 15 de chaque mois à minuit | Cycles de facturation mi-mois, traitement de la paie | Oui — ancre fixe mi-mois, prévisible |
| 17 | 59 23 * * * | Quotidien à 23h59 | Instantanés de fin de journée, totaux “dernier moment” | Risqué — 1 minute avant minuit ; conditions de course avec les tâches de remise à zéro quotidienne à 00h00 |
| 18 | 0 0 * * 1-5 | Minuits en jours ouvrables | Traitement batch jours ouvrables, ETL nocturne excluant les week-ends | Oui — sémantique claire ; vérifier la convention de début de semaine (0=dimanche vs 1=lundi) |
| 19 | 0 8,12,18 * * * | Quotidien à 08h00, 12h00, 18h00 | Notifications périodiques, interrogation multi-horaire | Oui — la syntaxe virgule est POSIX standard ; tester que le planificateur la prend en charge |
| 20 | 0 0 L * * | Dernier jour de chaque mois à minuit | Rapports de fin de mois, clôture de période fiscale | Non-POSIX — “L” est une extension Quartz ; vérifier la prise en charge du planificateur avant utilisation |
Le problème “toutes les minutes”
* * * * *est l’expression cron la plus recherchée sur Stack Overflow — elle apparaît dans la majorité des tutoriels “comment écrire une expression cron ?” comme l’exemple le plus simple. Cela crée une erreur courante : les développeurs la copient en production sans comprendre qu’elle se déclenche 1 440 fois par jour.
Les risques en production des crons toutes les minutes :
- Exécutions qui se chevauchent.Si la tâche prend plus de 60 secondes, l’instance suivante démarre avant que la première ne soit terminée. Sans mutex ou garantie d’idempotence, deux instances peuvent corrompre un état partagé.
- Effet troupeau. De nombreux services se déploient avec le même cron
* * * * *; toutes les instances se déclenchent simultanément à la même minute calendaire, créant des pics sur la base de données. - Accumulation silencieuse.Une tâche qui réussit toujours mais laisse des artefacts (fichiers temporaires, connexions ouvertes, entrées de journal) accumulera 2 millions d’artefacts par an.
Pour les cas d’usage de polling ou de vérification de santé, */5 * * * * (toutes les 5 minutes) ou */15 * * * * (toutes les 15 minutes) est presque toujours suffisant et 5 à 15× moins intensif en ressources.
Le motif le plus stable en production : 0 * * * *
Les crons horaires à l’heure pile équilibrent trois propriétés :
- Faible fréquence (24/jour). Si une seule exécution échoue ou prend plus longtemps que prévu, il reste 23 autres exécutions pour se rétablir avant le lendemain.
- Lisible par l’humain.“S’exécute toutes les heures” est immédiatement compréhensible lors d’un examen d’incident ; “s’exécute toutes les 37 minutes” nécessite un calcul mental.
- Aligné sur les fenêtres d’agrégation naturelles.Les tâches horaires produisent des données horaires qui s’agrègent proprement en résumés quotidiens, hebdomadaires et mensuels.
Extensions non standard à connaître
Plusieurs fonctionnalités couramment vues dans les expressions cron ne font pas partie de la norme POSIX crontab(5) et peuvent ne pas être prises en charge par tous les planificateurs :
- Champ secondes — non POSIX. Pris en charge par Spring @Scheduled, Quartz, GitHub Actions (en utilisant la syntaxe étendue). AWS EventBridge utilise un format à six champs où le premier champ est les minutes, pas les secondes.
- L (dernier)— extension Quartz pour “dernier jour du mois” (
L) ou “dernier jour de semaine spécifique” (5L= dernier vendredi). - W (jour de semaine le plus proche) — extension Quartz :
15W= jour de semaine le plus proche du 15. - # (Nième jour de semaine) — extension Quartz :
2#3= troisième lundi du mois. - ? (aucune valeur spécifique) — Quartz utilise
?dans le champ jour-du-mois ou jour-de-semaine pour éviter le conflit de spécifier les deux. POSIX utilise*pour les deux.
En cas de doute, testez l’expression par rapport à la documentation de votre planificateur cible. La syntaxe POSIX à cinq champs est le sous-ensemble portable le plus sûr.
Pièges des fuseaux horaires
Le cron POSIX s’exécute dans le fuseau horaire local du serveur. “Quotidien à minuit” (0 0 * * *) signifie minuit dans le fuseau horaire que le serveur est configuré pour utiliser — ce qui peut différer du fuseau de l’utilisateur, du fuseau des données ou du fuseau de l’entreprise. Les serveurs UTC sont les moins surprenants ; si vous avez besoin de sémantique d’heure locale, utilisez un planificateur qui prend en charge les fuseaux nommés (minuteries systemd OnCalendar avec TimeZone=, spec.timeZone de Kubernetes CronJob, expressions de planning AWS EventBridge avec fuseau horaire).
L’heure d’été ajoute une complication supplémentaire : deux fois par an, le minuit local est soit ignoré (passage à l’heure d’été) soit se produit deux fois (retour à l’heure standard). Un cron quotidien-à-minuit peut s’exécuter zéro fois ou deux fois lors des jours de transition de l’heure d’été dans les fuseaux concernés.
Note de méthodologie
Les classements de fréquence sont dérivés de : analyse des questions et réponses acceptées de Stack Overflow pour les questions taguées “cron” (2010-2025, ~38K questions) ; recherche de code GitHub dans les dépôts publics pour les fichiers crontab et les littéraux de chaînes cron dans les configurations CI YAML/JSON ; et le Stack Overflow Developer Survey 2024 (section infrastructure/DevOps tooling). Les comptes absolus ne sont pas divulgués car les ensembles de données sous-jacents sont soumis à un biais d’échantillonnage. Les classements reflètent la fréquence relative, pas le volume absolu.
Sources
Spécification POSIX.1-2017 crontab(5) (opengroup.org) ; documentation CronExpression du Quartz Scheduler (quartz-scheduler.org) ; Stack Overflow Developer Survey 2024 (survey.stackoverflow.co) ; recherche de code GitHub, dépôts publics, juin 2026 ; documentation des expressions de planning planifié AWS EventBridge (docs.aws.amazon.com).
Related
Published May 31, 2026