Générateur crontab et constructeur d'expressions cron

Qu'est-ce qu'une expression cron ?

# Linux crontab entry — runs every 15 minutes
*/15 * * * *  /usr/local/bin/poll-api.sh

# Kubernetes CronJob — weekdays at 9:00 AM UTC
apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-report
spec:
  schedule: "0 9 * * 1-5"
  timeZone: "UTC"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: report
              image: report-runner:1.0
          restartPolicy: OnFailure

# GitHub Actions workflow — hourly
on:
  schedule:
    - cron: '0 * * * *'

# AWS EventBridge — first of each month
ScheduleExpression: cron(0 0 1 * ? *)
# (Note: AWS uses the Quartz 6-field form with '?' for day-of-week)

Fonctionnalités clés

Variantes de cron et planificateurs

Exemples d'expressions cron

*/15 * * * *

0 9 * * 1-5

0 0 1 * *

*/5 9-17 * * 1-5

0 0 1 JAN,APR,JUL,OCT *

0 0 1 * 5

30 2 * * *

@daily

Comment construire une expression cron

1. 1

   Tapez ou collez une expression cron

   Saisissez une expression cron à cinq champs dans le champ ci-dessus (p. ex. */15 * * * *). L'outil analyse et valide pendant que vous tapez — coche verte pour valide, erreur rouge avec nom de champ pour invalide. Les macros comme @daily, @hourly, etc. sont aussi acceptées.

2. 2

   Ou ajustez les cinq champs

   Pas besoin de mémoriser l'ordre des champs — modifiez Minute, Heure, Jour du mois, Mois ou Jour de la semaine individuellement à l'aide des champs étiquetés. L'expression complète en haut se met à jour automatiquement. Utilisez * pour les jokers, */N pour les pas, a-b pour les plages et 1,3,5 pour les listes.

3. 3

   Choisissez un préréglage pour démarrer

   Touchez n'importe quelle puce de préréglage (Toutes les 15 minutes, En semaine à 9 h, etc.) pour charger une planification courante, puis ajustez les champs selon votre besoin précis. Onze préréglages couvrent les motifs que vous utiliserez réellement en production.

4. 4

   Vérifiez l'aperçu des prochaines exécutions

   Regardez les cinq dates et heures d'exécution à venir — basculez entre Local et UTC pour confirmer que la planification se déclenche au moment voulu. C'est le moyen le plus fiable de repérer le piège OR jour du mois / jour de la semaine du POSIX avant qu'il ne vous morde en production.

5. 5

   Copiez et collez dans votre planificateur

   Cliquez sur Copier pour récupérer l'expression. Collez-la dans votre crontab, votre timer systemd, le cron: GitHub Actions, AWS EventBridge, le schedule Kubernetes CronJob ou n'importe quel planificateur compatible cron. N'oubliez pas de vérifier le fuseau horaire du planificateur cible — voir la section Bonnes pratiques ci-dessous.

Erreurs cron courantes

# Intention : « premier vendredi du mois »
0 0 1-7 * 5
# En réalité : se déclenche les jours 1-7 du mois OU chaque vendredi — les deux conditions

# Utilisez un wrapper pour une vraie sémantique AND
0 0 * * 5  [ $(date +\%d) -le 7 ] && /votre-script
# OU laissez tomber une condition et acceptez la planification plus large

# Écrit par un dev US East, déployé sur un serveur UTC
0 9 * * *  /votre-rapport.sh
# Se déclenche à 9 h UTC = 4 h US East — pas ce que le dev voulait

# Verrouillez le fuseau, ou écrivez explicitement en UTC
CRON_TZ=America/New_York
0 9 * * *  /votre-rapport.sh

# Intention : toutes les 15 minutes
15 * * * *
# En réalité : une fois par heure, à la minute 15 (4 exécutions/heure de moins que voulu)

# Correct
*/15 * * * *
# Toutes les 15 minutes : minute 0, 15, 30, 45 de chaque heure

# 6 champs Quartz copiés dans un crontab Linux
0 0 9 * * 1-5
# Linux lit : minute=0, heure=0, jour=9, mois=*, jour-de-la-semaine=1-5
# = minuit les jours 9 dans les mois correspondant à des jours de la semaine — chaos

# POSIX 5 champs, retirez les secondes
0 9 * * 1-5
# = en semaine à 9 h 00

# 30 ou 31 février — ne s'exécute jamais
0 0 30 2 *
0 0 31 2 *
# S'analyse mais aucune planification ne se déclenche jamais

# Utilisez un motif « dernier jour ouvré de février » via script
0 0 28-29 2 *  [ $(date -d tomorrow +\%m) = 03 ] && /votre-script

# Quartz : « dernier vendredi du mois » — invalide en POSIX
0 0 ? * 6L *

# Approche wrapper POSIX pour dernier-vendredi
0 0 25-31 * 5  /votre-script
# S'exécute le vendredi entre le 25 et le 31 de n'importe quel mois

Cas d'usage courants

Tâches crontab Linux

Construisez et vérifiez des entrées pour /etc/crontab, /etc/cron.d/* ou les fichiers crontab -e par utilisateur. Utilisez l'aperçu des prochaines exécutions pour confirmer que la planification tombe à la bonne heure dans le fuseau configuré de votre serveur avant d'enregistrer.

Planifications Kubernetes CronJob

Générez le champ spec.schedule pour un Kubernetes CronJob. Kubernetes 1.27+ prend aussi en charge spec.timeZone — utilisez le sélecteur UTC pour concevoir votre planification en UTC, puis définissez explicitement timeZone afin d'éviter l'heure locale du nœud worker.

Workflows planifiés GitHub Actions

Construisez l'entrée cron: sous on.schedule. GitHub Actions tourne toujours en UTC — basculez l'aperçu en UTC pour confirmer votre planification. Évitez les intervalles inférieurs à 15 minutes ; le planificateur de GitHub saute les jobs à intervalle court sous charge.

Règles AWS EventBridge

Composez l'expression cron pour une règle EventBridge planifiée. Note : AWS utilise une syntaxe à six champs façon Quartz avec ? pour le jour de la semaine — cet outil émet du POSIX à cinq champs, que vous devrez convertir en préfixant les secondes (0) et en remplaçant le * dans l'un des champs jour par ?.

Pipelines planifiés GitLab CI

Vérifiez l'expression cron pour un pipeline CI planifié dans GitLab. GitLab utilise la syntaxe POSIX à cinq champs — ce qu'émet cet outil — et un sélecteur de date dans l'interface, mais la forme cron vous donne un contrôle plus fin pour les intervalles non standard.

Cloudflare Workers Cron Triggers

Construisez l'entrée [triggers.crons] dans wrangler.toml. Cloudflare utilise la syntaxe POSIX à cinq champs. L'intervalle minimum est d'une minute ; le worker tourne en UTC. Utilisez l'aperçu pour vérifier que le déclencheur se déclenche dans la fenêtre attendue.

Planifications Node.js node-cron

Construisez des expressions pour la bibliothèque node-cron, qui prend en charge à la fois POSIX à cinq champs et un champ secondes optionnel en tête. Tenez-vous à cinq champs sauf si vous avez spécifiquement besoin d'une précision inférieure à la minute — les expressions à six champs ne se portent pas vers crontab Linux.

Revue de code et documentation

Collez une expression cron d'une PR ou d'un runbook pour voir instantanément ce qu'elle fait — fini les devinettes sur 30 7 * * 1-5 ou la sortie d'une fiche de référence. La description en français clair est aussi excellente pour les commentaires en ligne et les fichiers README.

Référence de la syntaxe cron

Ordre des champs : M H J M S

Minute (0-59), Heure (0-23), Jour du mois (1-31), Mois (1-12), Jour de la semaine (0-6, 7 = dimanche aussi). Moyen mnémotechnique : « Ma Hauteur Joue Mal sur Sa scène ». Le champ jour de la semaine accepte à la fois les jetons numériques (0-6) et nommés (SUN-SAT, insensible à la casse).

Opérateurs

* = n'importe quelle valeur ; , = séparateur de liste (1,3,5) ; - = plage (1-5) ; / = pas (*/15, 5/10) ; noms : JAN-DEC pour le mois, SUN-SAT pour le jour de la semaine (insensible à la casse).

Macros (alias)

@yearly = 0 0 1 1 * ; @annually = 0 0 1 1 * ; @monthly = 0 0 1 * * ; @weekly = 0 0 * * 0 ; @daily = 0 0 * * * ; @midnight = 0 0 * * * ; @hourly = 0 * * * *. @reboot est une non-planification spéciale (s'exécute uniquement au démarrage) et est rejetée avec un message d'erreur explicatif.

Sémantique du jour POSIX (règle OR)

Lorsque LE jour du mois ET le jour de la semaine sont restreints (aucun n'est *), la planification s'exécute si L'UN OU L'AUTRE correspond — sémantique OR. Lorsqu'un seul est restreint, c'est lui qui décide. Lorsque les deux sont *, chaque jour correspond. Cette règle OR s'applique à vixie cron, BSD cron et à la plupart des implémentations POSIX ; Quartz utilise ? pour distinguer AND et OR.

Mode six champs (Quartz allégé)

Si votre entrée contient six jetons séparés par des espaces, l'outil traite le premier comme un champ secondes (0-59). Utile pour Quartz, @Scheduled(cron=...) de Spring et node-cron. NON portable vers crontab Linux ou les planificateurs POSIX — ils traiteraient vos secondes comme des minutes et décaleraient tout d'une position.

Ancrage de l'opérateur de pas

*/N est ancré à la plus petite valeur du champ : */15 dans minute = 0,15,30,45, et non « toutes les 15 à partir de maintenant ». Avec une base non joker : 5/15 dans minute = 5,20,35,50. Les valeurs de pas qui ne divisent pas la plage uniformément sauteront près du bouclage — c'est correct, pas un bug.

Bornes de validation

minute ∈ [0,59], heure ∈ [0,23], jour du mois ∈ [1,31], mois ∈ [1,12], jour de la semaine ∈ [0,7]. Les valeurs hors plage produisent une erreur au niveau du champ. Le jour du mois N'EST PAS validé par rapport au mois (0 0 31 2 * s'analyse correctement mais ne correspond jamais, car février n'a pas de jour 31 — l'aperçu des prochaines exécutions affichera « Aucune exécution à venir »).

Opérateurs Quartz rejetés

Le cron POSIX ne prend pas en charge les opérateurs Quartz ? (aucune valeur spécifique), L (dernier), W (jour ouvré le plus proche) ou # (nième jour de semaine). Cet outil les rejette avec un message clair « Opérateurs Quartz non pris en charge » plutôt que de les analyser silencieusement comme du POSIX invalide. Pour les planifications Quartz, utilisez un outil compatible Quartz ou le scheduler Spring.

Limite annuelle sur la recherche des prochaines exécutions

Le calcul des prochaines exécutions cherche jusqu'à 4 ans en avant ; les expressions qui correspondent moins souvent (p. ex. les motifs « 29 février ») afficheront « Aucune exécution à venir dans les 4 prochaines années ». C'est par conception, pour éviter une itération non bornée sur des motifs impossibles.

Bonnes pratiques pour les planifications cron

Utilisez UTC sur les serveurs, convertissez à l'affichage

Réglez vos serveurs en UTC (/etc/timezone ou TZ=UTC) et écrivez toutes les expressions cron en UTC. Convertissez en heure locale uniquement à l'affichage, dans vos tableaux de bord et rapports. Cela élimine toute une catégorie de bugs de fuseau horaire qui frappent le plus fort pendant les transitions d'heure d'été, lorsque les planifications en heure locale se déclenchent silencieusement deux fois ou sautent une exécution. Utilisez le sélecteur UTC de cet outil pour concevoir votre planification en UTC dès le départ.

Évitez le piège OR jour du mois / jour de la semaine du POSIX

Ne restreignez jamais à la fois le jour du mois ET le jour de la semaine sauf si vous voulez la sémantique OR. Si vous voulez « tous les lundis de janvier », écrivez 0 0 * 1 1 (le jour du mois est *) ; si vous voulez « le 1er de chaque mois », écrivez 0 0 1 * * (le jour de la semaine est *). La règle OR du POSIX signifie que 0 0 1 * 1 s'exécute le 1er ET tous les lundis — presque certainement pas ce que vous vouliez. L'aperçu des prochaines exécutions repérera cela si vous vérifiez avant de déployer.

Verrouillez explicitement le fuseau horaire de la planification

Les planificateurs modernes prennent en charge le fait de figer le fuseau horaire dans la définition de planification : CRON_TZ=America/New_York en haut d'un crontab (vixie cron 3.0+), spec.timeZone: "America/New_York" pour les Kubernetes CronJobs 1.27+, expression de planification avec ScheduleExpressionTimezone pour AWS EventBridge Scheduler. Verrouillez le fuseau explicitement plutôt que de vous appuyer sur le défaut du serveur — les fuseaux horaires des serveurs peuvent changer sans préavis lors des migrations d'infrastructure.

Répartissez la charge sur les minutes, pas à :00

Évitez 0 * * * * (toutes les heures à la minute 0) pour les jobs non critiques — à grande échelle, planifier de nombreuses choses exactement à :00 crée des pics de charge. Choisissez un décalage de minute aléatoire (23 * * * *, 41 * * * *) pour chaque job afin de répartir la charge. La même règle s'applique aux jobs quotidiens : 30 3 * * * est plus doux pour votre base de données que 0 3 * * * quand de nombreux jobs convergent à 3 h 00.

Rendez les jobs idempotents

Cron n'a pas de retentative intégrée, pas de prévention de chevauchement, pas de récupération d'exécution manquée. Votre job doit être sûr à exécuter plusieurs fois (idempotent) et auto-vérifiant. Au lieu de « envoyer le rapport à 9 h », concevez-le comme « envoyer le rapport du jour s'il n'a pas déjà été envoyé » — il s'auto-répare après une panne, une double planification accidentelle et les exécutions concurrentes. L'idempotence est une propriété du job, pas du planificateur, et c'est la pratique de fiabilité la plus importante.

Ajoutez un battement de cœur pour les planifications critiques

Le mode d'échec silencieux de cron est sa plus grande faiblesse — si la planification ne se déclenche pas, rien ne vous le dit. Pour les jobs critiques, faites en sorte que le job ping un service de battement de cœur (Healthchecks.io, Cronitor, Dead Man's Snitch) à la fin de chaque exécution ; le service vous alerte si le ping attendu n'arrive pas. Cela attrape à la fois l'échec du job et un mauvais déclenchement de la planification elle-même. Le palier gratuit couvre la plupart des besoins personnels et de petites équipes.

Vérifiez avec l'aperçu des prochaines exécutions avant d'expédier

Avant de déployer une nouvelle planification cron, regardez les cinq dates et heures d'exécution à venir dans l'aperçu de cet outil. Basculez entre Local et UTC. Confirmez que la planification tombe quand vous le voulez — pas cinq minutes trop tôt, pas le mauvais jour, sans sauter le week-end qui vous importait. L'aperçu est le test de production le moins cher possible.

Questions fréquentes