Parseur Cron & Testeur Crontab

Parseur Cron & Testeur Crontab

Analysez vos expressions cron en horaires lisibles. Inspectez les prochaines exécutions multi-fuseaux horaires, validez la syntaxe crontab et projetez les dates d'exécution.

Modèles prédéfinis
Nombre de jetons (Tokens)5/5
MIN
*/5
HOUR
*
DOM
*
MON
*
DOW
*
Cadence de planificationEvery 5 minutes past every hour.
Variables d'ordre supérieurExécution sécurisée
Durée d'exécution estimée1 minutes
Pipeline vectoriel SVG100 % En mémoire
LEX5 jetonsASTMasque binaire (Bitmask)POSIXCleanRUNSafeSLOT10 sorties
Valide
5 Champs•Standard POSIX (1 min)
Prochaines exécutions programmées(10 occurrences)
N°Heure locale cibleJour de la semaineCompte à reboursCréneau avec gigue (Jitter)Horodatage UTC (ISO)
1Nov 03, 2026, 03:20Tuein 3m 12sexact2026-11-03T03:20:00.482Z
2Nov 03, 2026, 03:25Tuein 8m 12sexact2026-11-03T03:25:00.482Z
3Nov 03, 2026, 03:30Tuein 13m 12sexact2026-11-03T03:30:00.482Z
4Nov 03, 2026, 03:35Tuein 18m 12sexact2026-11-03T03:35:00.482Z
5Nov 03, 2026, 03:40Tuein 23m 12sexact2026-11-03T03:40:00.482Z
6Nov 03, 2026, 03:45Tuein 28m 12sexact2026-11-03T03:45:00.482Z
7Nov 03, 2026, 03:50Tuein 33m 12sexact2026-11-03T03:50:00.482Z
8Nov 03, 2026, 03:55Tuein 38m 12sexact2026-11-03T03:55:00.482Z
9Nov 03, 2026, 04:00Tuein 43m 12sexact2026-11-03T04:00:00.482Z
10Nov 03, 2026, 04:05Tuein 48m 12sexact2026-11-03T04:05:00.482Z
Prochaine projection in 3m 12sFuseau horaire UTC
Métrique principaleSyntaxe AST valide
Efficience & Capacité5 champs (Standard POSIX)
Sortie nette10 SLOTS
Cadence annuellein 3m 12s
Conformité syntaxique24 / 24 HRS
Prochain déclenchement100 % Local

Traitement côté client

Calcul haute performance exécuté intégralement dans la mémoire du navigateur.

Zéro transmission serveur

Toutes les charges utiles restent strictement locales, sans aucune communication externe.

Export prêt pour la production

Formats de sortie épurés et optimisés, prêts pour un déploiement immédiat.

ToolsAA•Utilitaires web 100% privés côté client
Référence technique et guide d'architecture

Testeur Crontab & Analyseur Cron — Guide de référence

Analysez vos expressions cron en planifications claires et compréhensibles. Visualisez les prochains horodatages d'exécution par fuseau horaire, validez la syntaxe crontab et anticipez les dates de lancement.

Testeur Crontab & Analyseur Cron — Guide de référence — Architecture en mémoire côté client et flux de données
Testeur Crontab & Analyseur Cron — Guide de référence — Architecture en mémoire côté client et flux de données

Paramètres clés et contrôles

Champ Minute (Champ 1 en POSIX, Champ 2 dans Quartz)Ensemble d'entiers [0-59], Astérisque (*), Pas (/n), Intervalle (a-b), Liste (,)

Spécifie la minute exacte de l'heure à laquelle la tâche se déclenche (0-59). Évalué via des masques de bits de 60 bits avec vérification d'appartenance en O(1) ; la syntaxe de pas */15 déclenche l'exécution aux minutes 0, 15, 30 et 45 de chaque heure.

Par défaut : 0 (Début d'heure)
Champ Heure (Champ 2 en POSIX, Champ 3 dans Quartz)Ensemble d'entiers [0-23] Format 24 heures

Spécifie l'heure du jour au format 24 heures (0-23), où 0 représente minuit (00:00) et 23 représente 23:00. L'intervalle 9-17 correspond aux heures de bureau standard selon la norme ISO 8601 sur l'ensemble des fuseaux horaires IANA.

Par défaut : * (Chaque heure)
Champ Jour du mois (Champ 3 en POSIX, Champ 4 dans Quartz)Ensemble d'entiers [1-31], Point d'interrogation (?), Dernier (L), Jour ouvré le plus proche (W)

Définit le jour du mois civil de 1 à 31. Les dates invalides dépassant la durée réelle du mois (ex. 31 en avril, 30 en février) sont ignorées en toute sécurité lors de la vérification du roulement calendaire.

Par défaut : * (Chaque jour)
Champ Mois (Champ 4 en POSIX, Champ 5 dans Quartz)Ensemble d'entiers [1-12] ou alias à 3 lettres [JAN-DEC]

Spécifie le mois civil de 1 (janvier) à 12 (décembre). Les systèmes POSIX prennent en charge les chaînes de 3 lettres insensibles à la casse (JAN-DEC), associées en interne à un masque de bits de 12 bits.

Par défaut : * (Chaque mois)
Champ Jour de la semaine (Champ 5 en POSIX, Champ 6 dans Quartz)Ensemble d'entiers [0-7] ou alias à 3 lettres [SUN-SAT], Nième jour (#), Dernier (L)

Définit le jour de la semaine. Selon la norme POSIX IEEE 1003.1 et Vixie cron, les valeurs 0 et 7 désignent toutes deux le dimanche (1=lundi, ..., 6=samedi). Les abréviations insensibles à la casse (SUN-SAT) éliminent toute confusion d'indexation décalée.

Par défaut : * (Chaque jour de la semaine)
Champ Secondes (Champ 1 dans Quartz / Spring, omis en POSIX)Ensemble d'entiers [0-59] Haute résolution en secondes

Premier champ étendu haute résolution présent dans les ordonnanceurs à 6 champs (Quartz, Spring Framework). Le crontab standard UNIX à 5 champs ne gère pas les secondes et traite un sixième token initial comme une syntaxe invalide.

Par défaut : 0 (Zéro seconde)
Champ Année (Champ 7 optionnel dans Quartz, Champ 6 dans AWS EventBridge)Ensemble d'entiers [1970-2099], Astérisque (*), omis en POSIX

Champ d'année calendaire final, facultatif ou obligatoire selon les ordonnanceurs d'entreprise, servant à restreindre les tâches récurrentes à une période spécifique sans risque de boucle infinie.

Par défaut : * (Illimité / Chaque année)

Conseils de pro et bonnes pratiques

La présence simultanée du jour du mois et du jour de la semaine en POSIX applique un OU logique, pas un ET

Dans les spécifications standard de Vixie cron et POSIX IEEE 1003.1, lorsque le jour du mois (champ 3) et le jour de la semaine (champ 5) contiennent tous deux des valeurs explicites autres que des jokers (*), le planificateur les évalue avec une condition OU logique (disjonction). Par exemple, 0 0 13 * 5 ne s'exécute PAS uniquement le vendredi 13 ; il s'exécute le 13 de chaque mois AINSI QUE chaque vendredi de chaque mois. Pour limiter strictement l'exécution au vendredi 13, conservez * pour le jour de la semaine et filtrez le jour directement dans la charge utile de la commande bash : 0 0 13 * * [ $(date +\%u) -eq 5 ] && /opt/backup.sh.

Les valeurs de pas (*/N) se réinitialisent aux limites de champ et créent des intervalles modulo asymétriques

Une idée reçue fréquente consiste à penser que */25 * * * * s'exécutera en continu toutes les 25 minutes. En réalité, les expressions de pas cron s'évaluent strictement dans la limite 0-59 de l'heure : 59 / 25 ne génère des exécutions qu'aux minutes 0, 25 et 50. Lorsque l'horloge passe à l'heure suivante (par exemple de 01:50 à 02:00), le champ redémarre à la minute 0, provoquant un intervalle de 10 minutes au lieu d'une période de 25 minutes. Si vous avez besoin d'intervalles stricts chevauchant les limites horaires, privilégiez les minuteurs monotones Systemd (OnUnitActiveSec=25m) ou des files de tâches avec gestion par seau à jetons (token-bucket).

Standardisez toujours vos crontabs serveurs sur UTC pour éviter les conflits liés au changement d'heure

L'exécution de démons crontab sur des fuseaux horaires locaux soumis au changement d'heure (heure d'été / hiver) entraîne de sévères anomalies d'ordonnancement. Lors du passage à l'heure d'été (+1 heure), les tâches programmées entre 02:00 et 02:59 sont totalement ignorées car cette heure d'horloge n'existe pas. Lors du passage à l'heure d'hiver (-1 heure), les tâches de ce créneau s'exécutent deux fois. Configurez systématiquement les horloges système et l'environnement crontab sur TZ=UTC, et gérez les décalages d'heures ouvrées de manière statique pour éliminer les doubles exécutions et les sauts de tâches.

Les signes pourcentage (%) dans Vixie cron doivent impérativement être échappés avec des antislashs

Dans les fichiers crontab, le caractère pourcentage % non échappé possède une signification syntaxique particulière : il est converti par le démon cron en saut de ligne, et toutes les données suivantes sont transmises sur l'entrée standard (stdin) de la commande. L'exécution directe de commandes de formatage comme date +%Y-%m-%d entraînera une troncature silencieuse ou des erreurs de syntaxe cryptiques. Vous devez échapper chaque signe pourcentage sous la forme date +\%Y-\%m-\%d ou encapsuler l'appel dans un script shell externe exécutable.

Pièges courants et dépannage

⚠️Erreur de syntaxe crontab : collage d'une expression à 6 ou 7 champs dans /etc/crontab sous Linux

Le crontab standard UNIX/Linux attend exactement 5 champs délimités par des espaces. Les expressions issues de Java Quartz, Spring Framework ou AWS EventBridge comportent un champ initial pour les secondes (ex. 0 0 12 * * ?) ou un champ final pour l'année. Lorsqu'elles sont collées dans un crontab standard, le 6e élément est interprété comme le nom d'utilisateur ou la commande, provoquant un échec syntaxique. Supprimez le champ initial des secondes ainsi que l'année finale, et remplacez les points d'interrogation ? par des astérisques standard *.

⚠️La tâche cron s'exécute au mauvais horaire local ou à une heure inattendue

Le démon crontab évalue les horaires en se basant sur le fuseau horaire matériel et noyau du système (/etc/timezone ou /etc/localtime). Dans les environnements cloud (instances AWS EC2, conteneurs Docker, nœuds Kubernetes), l'horloge système est par défaut sur UTC. Une tâche programmée avec 0 9 * * 1-5 dans l'intention de viser 09:00 heure de Paris s'exécutera à 09:00 UTC (soit 10:00 ou 11:00 heure française selon la saison). Ajoutez explicitement CRON_TZ=Europe/Paris en haut de votre fichier crontab (Vixie cron 4.1+) ou convertissez directement vos horaires en UTC.

⚠️La tâche cron ne démarre pas ou les variables d'environnement ($PATH) sont introuvables

Cron exécute les tâches dans un sous-shell non interactif et sans session de connexion, avec un PATH minimal par défaut (généralement /usr/bin:/bin). Les utilitaires situés dans /usr/local/bin, ~/.nvm ou /opt/homebrew échouent alors avec l'erreur command not found. Définissez explicitement PATH=/usr/local/bin:/usr/bin:/bin au début de votre crontab, ou invoquez tous vos exécutables et binaires avec leur chemin absolu (par exemple /usr/bin/python3 /opt/app/job.py).

⚠️Fréquence d'exécution doublée inattendue lors de la combinaison du jour du mois et du jour de la semaine

Comme l'impose le standard POSIX IEEE 1003.1, dès lors que les champs jour du mois et jour de la semaine contiennent tous deux des valeurs autres que *, leur évaluation opère comme une disjonction logique (OU) et non une conjonction (ET). La tâche se déclenche dès que la date correspond OU dès que le jour de la semaine correspond. Pour exiger la correspondance simultanée des deux critères, définissez le jour de la semaine sur * et intégrez un test de date POSIX dans la commande : 0 3 1-7 * * [ $(date +\%u) -eq 1 ] && /opt/premier-lundi.sh.

Foire aux questions (FAQ)

Comment calculer précisément la prochaine heure d'exécution d'une expression cron ?▼

La prochaine échéance est calculée en avançant un horodatage de référence ISO 8601 minute par minute (ou seconde par seconde pour les moteurs à 6 champs) et en évaluant chaque candidat par rapport à des masques de 64 bits précompilés via des opérations logiques ET au niveau du bit avec une complexité par étape en O(n). Lorsque l'ensemble des champs concorde simultanément — en respectant la logique d'union OU entre jour du mois et jour de la semaine selon POSIX —, l'horodatage est validé comme instant d'exécution. Dans les bacs à sable navigateurs, l'analyse de l'AST et les projections s'exécutent entièrement dans la mémoire JavaScript isolée, sans aucun transfert de données vers un serveur.

Quelle est la différence entre le cron standard Linux à 5 champs et le cron Quartz à 6 champs ?▼

Le cron standard POSIX/Linux repose sur 5 champs séparés par des espaces (Minute, Heure, Jour du mois, Mois, Jour de la semaine) avec une granularité d'une minute, tandis que les planificateurs Java Quartz et Spring Framework utilisent 6 ou 7 champs en ajoutant au début un champ obligatoire de Secondes (0-59) et éventuellement à la fin un champ Année (1970-2099). De plus, Quartz introduit des caractères spéciaux tels que ? (champ sans contrainte) et L (dernier jour du mois ou de la semaine), qui provoquent des erreurs de syntaxe fatales s'ils sont injectés dans un crontab UNIX standard.

Quelle est la différence entre l'astérisque (*) et la barre oblique (/pas) dans la syntaxe cron ?▼

L'astérisque (*) agit comme un caractère générique universel correspondant à chaque entier valide dans le domaine du champ (par exemple, les minutes de 0 à 59), tandis que la barre oblique (/pas) définit un intervalle modulo qui n'évalue que des pas discrets à partir d'un index de base dans les limites du champ. Par exemple, */15 cible les minutes 0, 15, 30 et 45, alors que 10-30/5 restreint la séquence au sous-intervalle donné pour cibler 10, 15, 20, 25 et 30.

Pourquoi 0 0 13 * 5 s'exécute-t-il tous les vendredis plutôt que seulement le vendredi 13 ?▼

Conformément à la norme POSIX IEEE 1003.1, si le champ du jour du mois (champ 3) et celui du jour de la semaine (champ 5) contiennent tous deux des valeurs explicites autres qu'un astérisque, l'ordonnanceur applique un opérateur logique OU (disjonction) et non un ET (conjonction). Par conséquent, la tâche se lance le 13 de n'importe quel mois ainsi que chaque vendredi, quelle que soit la date. Pour obtenir une stricte condition ET, configurez le jour de la semaine avec * et testez le jour de la semaine dans le script de commande avec [ $(date +\%u) -eq 5 ].

Que signifient le point d'interrogation (?) et la lettre L dans les expressions cron ?▼

Dans les dialectes cron Quartz, Spring et AWS EventBridge, le point d'interrogation (?) indique l'absence de valeur spécifique afin de lever l'ambiguïté entre le jour du mois et le jour de la semaine, tandis que le caractère L signifie « Last » (dernier), comme le dernier jour calendaire du mois ou le dernier vendredi avec 5L. Les crontabs standard POSIX IEEE 1003.1 ne reconnaissent ni ? ni L et rejettent toute expression qui les contient comme syntaxiquement invalide.

Quel est l'impact du passage à l'heure d'été et à l'heure d'hiver sur les tâches cron ?▼

Lors du passage à l'heure d'été (avance d'une heure), les tâches planifiées sur le créneau sauté (généralement entre 02:00:00 et 02:59:59) ne sont pas exécutées du tout car cette heure n'existe pas dans le calendrier civil. Inversement, lors du passage à l'heure d'hiver (recul d'une heure), les tâches situées dans l'heure répétée s'exécutent deux fois, à moins que le système ne soit calé sur UTC. Pour éviter les omissions ou les doublons en production, les serveurs doivent toujours conserver leurs horloges matérielles et leurs démons crontab configurés sur le fuseau UTC.

Outils et utilitaires connexes

Tous les outils →
Générateur GraphQL vers TypeScriptDéveloppement

Convertissez vos schémas SDL et requêtes GraphQL en types, interfaces, énumérations et résolveurs TypeScript. Génération instantanée dans le navigateur, sans configuration ni transfert serveur.

Ouvrir l'outil→
Convertisseur HTML en Markdown (GFM)Développement

Convertissez du code HTML en Markdown GitHub Flavored (GFM) avec tableaux, blocs de code et nettoyage d'extraits web. Supprimez les styles inline et exportez des fichiers .md propres.

Ouvrir l'outil→
Comparateur de Texte & Diff CheckerDéveloppement

Comparez vos textes, codes et fichiers avec notre comparateur de diff instantané. Visualisez les écarts côte à côte ou en ligne au caractère près, ignorez les espaces et exportez vos patchs unifiés.

Ouvrir l'outil→
Générateur de Balises Canoniques & URLDéveloppement

Générez des balises rel=canonical et en-têtes HTTP valides. Supprimez les paramètres de suivi, normalisez les URL et éliminez le contenu dupliqué en SEO.

Ouvrir l'outil→
Convertisseur cURL en Fetch (JS & Node)Développement

Convertissez instantanément vos commandes cURL en syntaxe Fetch API. Analysez en-têtes HTTP, tokens d'authentification, cookies et payloads JSON en code JavaScript async/await moderne.

Ouvrir l'outil→
Validateur Sitemap XML & Syntaxe URLDéveloppement

Validez instantanément vos sitemaps XML et fichiers d'index. Vérifiez le seuil des 50 000 URLs, la syntaxe W3C Datetime, les balises hreflang, schémas médias et erreurs Google Search Console.

Ouvrir l'outil→