Aide-mémoire et exemples pratiques sur les expressions Cron
Qu'est-ce qu'une expression Cron ?
Une expression cron est une courte chaîne de caractères indiquant à un planificateur quand exécuter une tâche récurrente. Sous Unix et Linux, cron utilise cinq champs de date et d'heure, dans cet ordre fixe : minute, heure, jour du mois, mois et jour de la semaine. Une ligne du fichier crontab de l'utilisateur place une commande après ces cinq champs, et le démon cron exécute cette commande lorsque ces champs correspondent à l'heure actuelle.
Voici l'exemple le plus courant en production :
texte0 2 * * *
En clair : exécuter chaque jour à 02h00 (2h00 du matin) dans le fuseau horaire configuré par le planificateur.
Note de compatibilité : Ce guide commence par l'utilisation de cron sous Unix/Linux avec cinq champs. D'autres planificateurs peuvent utiliser un nombre de champs différent, un fuseau horaire différent ou des caractères spéciaux. Les expressions Quartz, par exemple, utilisent généralement six ou sept champs, incluant les secondes. Amazon EventBridge Scheduler utilise également six champs, incluant l'année.
Syntaxe de Cron : Les cinq champs
Les cinq champs sont positionnels. Les lire de gauche à droite est la méthode la plus rapide pour décoder une expression.
texte┌──────────── minute (0–59) │ ┌────────── heure (0–23) │ │ ┌──────── jour du mois (1–31) │ │ │ ┌────── mois (1–12) │ │ │ │ ┌──── jour de la semaine (variable selon la plateforme ; POSIX utilise 0 pour dimanche) │ │ │ │ │ * * * * *
| Position | Champ | valeurs typiques | Exemple | Signification |
|---|---|---|---|---|
| 1 | Minute | 0–59 | 30 * * * * | À 30 minutes après chaque heure |
| 2 | Heure | 0–23 | 0 6 * * * | Tous les jours à 6h00 |
| 3 | Jour du mois | 1–31 | 0 0 1 * * | Minuit le 1er |
| 4 | Mois | 1–12 | 0 0 1 7 * | Minuit le 1er juillet |
| 5 | Jour de la semaine | POSIX 0–6 avec 0 = dimanche | 0 12 * * 1 | Lundi à 12h00 |
Deux formats de crontab sont importants, car les confondre est une erreur classique :
- A crontab utilisateur La ligne contient les cinq champs de planification suivis de la commande à exécuter.
- A crontab système ligne (par exemple
/etc/crontabou des fichiers dans/etc/cron.d) contient les cinq champs de planification, puis un nom d'utilisateur, puis la commande.
Si vous collez une ligne crontab utilisateur dans un fichier crontab système, cron tentera d'interpréter le premier mot de votre commande comme un nom d'utilisateur. Consultez toujours la documentation de votre plateforme avant de copier une planification entre fichiers ou entre services.
Caractères spéciaux de Cron
Quatre opérateurs sont standardisés dans le cron de style POSIX et dans les implémentations Linux courantes dérivées de Vixie cron.
| Symbole | But | Exemple | Signification |
|---|---|---|---|
* | Chaque valeur valide | */5 * * * * | Toutes les 5 minutes |
, | Une liste | 0 9,17 * * * | À 9h00 et à 17h00 |
- | Une gamme inclusive | 0 9-17 * * 1-5 | À chaque heure pile, de 9h00 à 17h00, du lundi au vendredi |
/ | Un intervalle de marche | */15 * * * * | Toutes les 15 minutes |
POSIX définit lui-même l'astérisque, la liste des virgules et la plage des tirets. L'opérateur d'étape / provient de l'extension Vixie cron, où suivre une plage avec / on parcourt cette plage par sauts, et des étapes sont également autorisées après un astérisque.
L'intervalle entre les étapes suit l'horloge et le calendrier, et non le temps d'achèvement de votre tâche. */5 * * * * Les tirs ont lieu à la minute 0, 5, 10, etc. Cela ne signifie pas “ cinq minutes après la fin du tir précédent ”.”
Opérateurs et macros spécifiques à la plateforme
Des symboles tels que
?,L,W, et#, plus des macros telles que@reboot,@heure,@tous les jours,@hebdomadaire,@mensuel, et@annuel, Ces fonctionnalités sont spécifiques à l'implémentation. Elles existent dans certains planificateurs et pas dans d'autres, et leur comportement diffère selon le planificateur. La documentation relative aux cron Linux de type Vixie/Cronie les décrit.@-macros et valeurs nommées pour le mois et le jour de la semaine.L,W, et#sont des jetons de style Quartz, et Quartz utilise?dans les champs de jour. Kubernetes CronJob prend en charge@-macros et friandises?comme équivalent à*. Vercel Cron Jobs rejette les alias de nom tels queLUNouJANEntièrement. N'utilisez ces méthodes que si elles sont mentionnées dans la documentation de votre planificateur cible.
Aide-mémoire sur les expressions Cron : exemples courants
Chaque expression ci-dessous respecte la syntaxe standard Unix/Linux à cinq champs. Les heures sont affichées au format 24 heures et interprétées selon le fuseau horaire configuré par le planificateur.
Horaires à la minute et à l'heure près
| Expression | Anglais simple |
|---|---|
* * * * * | Chaque minute de chaque jour |
*/5 * * * * | Toutes les 5 minutes (minute 0, 5, 10, …) |
*/10 * * * * | Toutes les 10 minutes |
*/15 * * * * | Toutes les 15 minutes (:00, :15, :30, :45) |
*/30 * * * * | Toutes les 30 minutes (:00 et :30) |
C’est avec des planifications inférieures à une heure que les problèmes de fiabilité apparaissent en premier. Certaines plateformes gérées refusent les planifications trop fréquentes : GitHub Actions limite l’intervalle minimal pris en charge à 5 minutes.
Horaires horaires
| Expression | Anglais simple |
|---|---|
0 * * * * | Au début de chaque heure |
15 * * * * | À 15 minutes après chaque heure |
0 */2 * * * | Toutes les 2 heures, à l'heure pile (00:00, 02:00, 04:00, …) |
5,35 * * * * | Deux fois par heure, à 0:05 et 0:35 |
Des minutes hallucinantes avec une liste comme 5,35 Cela s'avère utile en pratique. Si des dizaines de tâches se lancent simultanément à la minute 0, elles se disputent les ressources du processeur, les connexions à la base de données et les limites de débit de l'API au même instant.
Horaires quotidiens
| Expression | Anglais simple |
|---|---|
0 0 * * * | Tous les jours à minuit (00:00) |
0 2 * * * | Tous les jours à 02h00 (2h00 du matin) |
30 6 * * * | Tous les jours à 06h30 (6h30 du matin) |
45 23 * * * | Tous les jours à 23h45 (23h45) |
Horaires de semaine et horaires hebdomadaires
| Expression | Anglais simple |
|---|---|
0 9 * * 1-5 | À 9h00, du lundi au vendredi |
30 8 * * 1-5 | À 8h30, du lundi au vendredi |
0 0 * * 0 | À minuit dimanche |
0 10 * * 0,6 | À 10h00 le dimanche et le samedi |
La numérotation des jours de la semaine dépend de la plateforme. POSIX définit les chiffres de 0 à 6, 0 représentant le dimanche. De nombreuses implémentations cron sous Linux acceptent les chiffres de 0 à 7, où 0 et 7 désignent tous deux le dimanche, et acceptent également les noms. Quartz utilise quant à lui les chiffres de 1 à 7 pour son champ « jour de la semaine », et AWS EventBridge Scheduler utilise également les chiffres de 1 à 7. DIM-SAM. Veuillez vérifier la numérotation dans la documentation de votre planificateur avant de vous fier à un horaire de week-end ou de semaine.
Calendriers mensuels et annuels
| Expression | Anglais simple |
|---|---|
0 0 1 * * | Minuit le 1er de chaque mois |
30 2 1 * * | 2h30 le 1er de chaque mois |
0 0 1 1 * | Minuit le 1er janvier, une fois par an |
0 0 1 1,4,7,10 * | Minuit le 1er janvier, avril, juillet et octobre |
“ Dernier jour du mois ” n'est pas portable dans une tâche cron de base à cinq champs. Il n'existe pas d'opérateur standard pour cela ; ne le représentez donc pas par une expression générique. Quartz fournit une solution. L jeton dans son propre dialecte, et EventBridge Scheduler liste L Cette fonction ne prend pas en compte le jour du mois ni le jour de la semaine, mais elle n'a pas sa place dans une crontab Linux. Sous Linux, gérez la logique de fin de mois directement dans votre script, par exemple en l'exécutant quotidiennement et en s'arrêtant sauf si demain est le 1er du mois.
Comment lire une expression Cron
*/5 * * * *
texte*/5 * * * *
| Champ | Valeur | En lisant |
|---|---|---|
| Minute | */5 | Toutes les 5 minutes, à partir de 0 |
| Heure | * | Toutes les heures |
| Jour du mois | * | Tous les jours |
| Mois | * | Chaque mois |
| Jour de la semaine | * | Chaque jour de la semaine |
En langage naturel : toutes les 5 minutes, 24 h/24 et 7 j/7. Attention : la grille des minutes n’est pas affectée par le fuseau horaire, mais les horodatages des journaux et toute logique basée sur la date dans votre script le sont.
0 9 * * 1-5
texte0 9 * * 1-5
| Champ | Valeur | En lisant |
|---|---|---|
| Minute | 0 | À l'heure |
| Heure | 9 | 09:00 |
| Jour du mois | * | N'importe quelle date |
| Mois | * | N'importe quel mois |
| Jour de la semaine | 1-5 | Du lundi au vendredi |
En langage naturel : à 9 h 00 (9 h 00 du matin) en semaine. Attention au fuseau horaire : 9 h 00 dans quel fuseau horaire ? Sur un serveur Linux, il s’agit généralement de l’heure locale du serveur ; par conséquent, la même expression peut s’exécuter à une heure différente de celle attendue par vos utilisateurs.
30 2 1 * *
texte30 2 1 * *
| Champ | Valeur | En lisant |
|---|---|---|
| Minute | 30 | À 30 heures |
| Heure | 2 | 2 heures |
| Jour du mois | 1 | Le 1er |
| Mois | * | Chaque mois |
| Jour de la semaine | * | Non restreint |
En langage naturel : à 2 h 30 (2 h 30 du matin) le premier jour de chaque mois. Attention aux fuseaux horaires : les tâches de facturation et de reporting mensuelles programmées aux alentours de minuit ou lors du passage à l’heure d’été/d’hiver sont les plus susceptibles d’être exécutées à une date incorrecte.
Jour du mois vs. Jour de la semaine
L'existence de ces deux champs “ jour ” s'explique par le fait que les utilisateurs décrivent les horaires de deux manières différentes : par date (“ le 15 ”) et par jour de la semaine (« tous les vendredis »). Cron conserve les deux, et leur interaction représente un véritable risque pour la production.
Dans les implémentations cron de style POSIX et les implémentations Linux courantes dérivées de Vixie/Cronie, lorsque le jour du mois et le jour de la semaine sont tous deux restreints plutôt que *, une tâche peut s'exécuter lorsque soit Les champs correspondent. D'autres planificateurs peuvent utiliser une sémantique différente ou restreindre cette combinaison. La page de manuel Linux l'indique clairement : les commandes s'exécutent lorsque les champs minute, heure et mois correspondent. et Au moins un des deux champs de jour correspond. POSIX décrit la même logique d'alternative lorsque les deux champs de jour sont spécifiés comme éléments ou listes.
Regardez cette expression :
texte0 0 15 * 5
Sous Unix/Linux, ce processus peut s'exécuter à minuit le 15 de chaque mois. et Tous les vendredis à minuit. Cela ne signifie pas forcément “ uniquement les vendredis 15 ”. En moyenne, cela représente cinq ou six passages par mois, et non un seul.
D'autres plateformes divergent nettement sur ce point. Vercel Cron Jobs ne permet pas de définir simultanément les deux champs de jour : lorsqu'une valeur est renseignée, l'autre doit être vide. *. AWS EventBridge Scheduler nécessite un ? dans un champ de jour lorsque l'autre est spécifié. Quartz utilise ? dans le même but.
Recommandations plus sûres :
- Utiliser
*en une journée sur le terrain, sauf si vous avez vérifié le comportement souhaité sur votre plateforme. - Utilisez des tâches distinctes ou une logique d'application au sein de la tâche pour les règles de calendrier complexes telles que “ le troisième vendredi ” ou “ le dernier jour ouvrable ”.”
- Validez l'expression par rapport au planificateur et à la version exacts que vous utiliserez pour le déploiement, et non par rapport à une référence cron générale.
Fuseaux horaires et heure d'été de Cron
Une expression cron ne prend pas en charge un fuseau horaire universel. Les cinq mêmes champs peuvent avoir trois significations différentes selon l'endroit où ils sont exécutés :
- Heure locale du serveur. Un démon cron Linux évalue les planifications par rapport à l'heure configurée sur l'hôte. Certaines implémentations cron Linux prennent également en charge un
CRON_TZvariable qui définit un fuseau horaire pour une tâche cron spécifique, les horodatages des journaux étant toujours tirés du fuseau horaire local du démon.CRON_TZcomme spécifique à l'implémentation. - Une valeur par défaut de la plateforme, telle que UTC. GitHub Actions exécute par défaut les flux de travail planifiés en UTC. Vercel Cron Jobs utilise toujours l'UTC et ne propose pas de champ de fuseau horaire par tâche.
- Un paramètre de fuseau horaire IANA explicite. Kubernetes CronJob utilise
.spec.timeZone. GitHub Actions accepte désormais une optionfuseau horairevaleur associée à une entrée cron. EventBridge Scheduler peut évaluer les planifications cron en UTC ou dans un fuseau horaire que vous spécifiez.@Programméa unzonecet attribut utilise par ailleurs la zone par défaut du serveur.
Le passage à l'heure d'été engendre deux types de dysfonctionnements distincts, dont la gestion dépend du planificateur. La documentation Linux classique de cron est claire à ce sujet : lors d'un passage à l'heure d'été, les heures locales inexistantes ne correspondent jamais, les tâches correspondantes ne s'exécutent donc pas ; de même, lors d'un passage à l'heure d'hiver, les tâches correspondantes s'exécutent deux fois. GitHub Actions adopte une approche différente pour les planifications prenant en compte les fuseaux horaires : une heure manquée est reportée à la prochaine heure valide, par exemple, une planification à 2 h 30 est décalée à 3 h 00.
Conseils pratiques pour les travaux sensibles :
- Pour la facturation, les rapports, les sauvegardes et les tâches de conformité, privilégiez le fuseau horaire UTC ou un fuseau horaire à décalage fixe, puis effectuez la conversion pour l'affichage. Le fuseau horaire UTC ne comporte pas de changement d'heure.
- Pour les messages destinés aux clients qui doivent être reçus à une heure locale, utilisez une plateforme qui prend en charge un fuseau horaire IANA explicite et acceptez que l'heure UTC change deux fois par an.
- Évitez de programmer des tâches importantes entre 1 h et 3 h, heure locale, dans les zones appliquant l'heure d'été. Durant cette période, les tâches sont souvent ignorées ou dupliquées.
- Consultez toujours un aperçu de la prochaine exécution avant le déploiement. Les aperçus révèlent les erreurs de décalage d'une heure et de date incorrecte qu'une simple expression masque.
Exemple spécifique à Kubernetes (et non à la syntaxe générique des crontab) :
texteapiVersion: batch/v1 kind: CronJob metadata: name: nightly-report spec: schedule: "0 2 * * *" timeZone: "Europe/London" jobTemplate: spec: template: spec: containers: - name: report image: your-registry/report:1.0 restartPolicy: OnFailure
Kubernetes rejette TZ ou CRON_TZ une erreur de validation s'est produite dans la chaîne de planification ; le fuseau horaire doit donc être saisi dans le fuseau horaire champ.
Exemple spécifique à GitHub Actions (et non à la syntaxe générique de crontab) :
textesur : planification : - cron : '30 5 * * 1-5' fuseau horaire : "America/New_York"'
Cela se déroule à 5h30, heure de New York, du lundi au vendredi.
Note de compatibilité Vercel : Les tâches Cron de Vercel utilisent cinq champs numériques et les interprètent systématiquement en UTC, sans option de fuseau horaire. Si votre équipe souhaite 9 h 00 à Londres, vous devez calculer vous-même l'heure UTC et la vérifier à nouveau lors du passage à l'heure d'été britannique.
Formats Cron par plateforme
| Plateforme/contexte | Format de champ typique | Approche par fuseau horaire | Note importante |
|---|---|---|---|
| crontab utilisateur Unix/Linux | Cinq champs, puis la commande | Heure locale de l'hôte ; certaines implémentations la prennent en charge CRON_TZ par table | Le jour de la semaine accepte généralement les chiffres de 0 à 7, 0 ou 7 représentant le dimanche, plus les noms. |
| crontab système Unix/Linux | Cinq champs, puis un nom d'utilisateur, puis la commande | Identique au démon cron hôte | Le champ supplémentaire « nom d'utilisateur » fait toute la différence ; l'omettre provoque un saut de ligne. |
| Tâche planifiée Kubernetes | Cinq champs dans .spec.schedule, avec les valeurs d'étape Vixie et @-macros | .spec.timeZone avec un nom IANA ; sinon, la zone locale du contrôleur | ? se comporte comme *; TZ/CRON_TZ sont rejetés dans le calendrier |
| Tâches Cron Vercel | Cinq champs numériques | Toujours en UTC, aucune option par tâche | Non LUN/JAN Les alias, le jour du mois et le jour de la semaine ne peuvent pas être définis simultanément. |
| Planification des actions GitHub | Cinq champs POSIX sous programmé | UTC par défaut ; IANA optionnel fuseau horaire valeur | L'intervalle le plus court est de 5 minutes ; les courses peuvent être retardées en cas de forte charge. |
| Planificateur de quartz | Six ou sept champs, y compris les deuxièmes et l'année optionnelle | Configuré dans le planificateur/déclencheur, et non dans l'expression | ?, L, W, et # Ce sont des jetons Quartz ; le jour de la semaine est de 1 à 7. |
| Autres planificateurs et bibliothèques cloud | Variable : EventBridge Scheduler utilise six champs avec l’année ; Printemps @Programmé utilise six champs commençant par secondes | EventBridge prend en charge UTC ou un fuseau horaire choisi ; Spring utilise un zone attribut | Consultez la documentation de la plateforme ; le nombre de champs et les règles relatives aux champs par jour diffèrent. |
Tout élément non répertorié dans la documentation de votre plateforme doit être considéré comme non pris en charge jusqu'à ce que vous l'ayez testé.
Erreurs courantes liées à Cron et leurs solutions
| Problème | Cause probable | Solution plus sûre |
|---|---|---|
| Le planificateur rejette catégoriquement l'expression. | Une expression Quartz ou Spring à six champs collée dans un planificateur à cinq champs | Commencez par compter les champs ; réécrivez pour le dialecte cible au lieu de supprimer aveuglément. |
| L'expression fonctionne dans un service, mais échoue dans un autre. | En supposant que la syntaxe de cron soit universelle | Vérifiez le nombre de champs, les valeurs autorisées et les caractères spéciaux dans la documentation cible. |
| Le travail du week-end ne prend jamais feu | En supposant les deux 0 et 7 signifie toujours dimanche | POSIX utilise 0 pour le dimanche ; de nombreuses implémentations Linux acceptent également 7, mais la prise en charge varie, alors consultez la documentation de votre planificateur. |
| Le travail commence à une heure indue | Ignorer le fuseau horaire du planificateur ; les plateformes fonctionnant uniquement en UTC sont courantes | Définissez un fuseau horaire explicite lorsque cela est possible, ou convertissez-le délibérément en UTC. |
| Emploi ignoré ou dupliqué deux fois par an | Changements d'heure ; cron classique ne correspond jamais aux heures sautées et correspond deux fois aux heures doublées | Utilisez le fuseau horaire UTC pour les tâches critiques, ou un planificateur qui documente son comportement en matière d'heure d'été. |
| La tâche s'exécute beaucoup plus souvent que prévu. | Les deux champs de jour sont restreints, donc l'un ou l'autre peut correspondre. | Laisser un champ d'un jour comme *, ou divisés en emplois distincts |
| Les courses s'accumulent de manière inattendue | Traitement */5 en raison d'un délai après la fin de l'exécution précédente | Les étapes suivent l'horloge ; utilisez un ordonnanceur à délai fixe si vous avez besoin d'une synchronisation basée sur des intervalles. |
| Les exécutions simultanées corrompent les données | La durée d'exécution dépasse l'intervalle prévu. | Encadrez la commande par un verrou, par exemple. flock -n /tmp/job.lock /chemin/vers/job.sh; dans Kubernetes ensemble concurrencyPolicy : Interdire |
| Une tâche ponctuelle se déclenche de manière répétée | Utilisation d'une planification cron récurrente pour un événement unique | Utilisez un mécanisme ponctuel tel qu'une invocation planifiée à un instant précis ou une tâche mise en file d'attente |
| Des échecs silencieux que personne ne remarque | Aucun journal, alerte, nouvelle tentative ni idempotence | Redirigez la sortie standard et l'erreur standard vers un journal, ajoutez des alertes et concevez des tâches reproductibles en toute sécurité. |
| Les identifiants se retrouvent dans les listes de processus et l'historique. | Secrets saisis directement dans la ligne de commande crontab | Lire les secrets à partir des variables d'environnement ou d'un gestionnaire de secrets dans le script |
| Un planning non testé perturbe la production | Déploiement direct sur la charge de travail réelle | Commencez par tester avec une commande inoffensive, par exemple. * * * * * /bin/date >> /tmp/cron-test.log 2>&1, puis consultez le journal |
Deux points concernant la fiabilité méritent d'être soulignés. Cron ne garantit pas des temps d'exécution précis : GitHub Actions avertit que les workflows planifiés peuvent être retardés en période de forte charge et être supprimés de la file d'attente. Kubernetes indique qu'une tâche Cron crée un Job. environ Kubernetes prévoit que deux tâches (ou aucune) peuvent être créées à chaque échéance planifiée. Vos tâches doivent donc être idempotentes. Kubernetes cesse également de démarrer des tâches après plus de 100 échecs de planification et consigne une erreur. Il est donc important de prévoir les retards, les doublons et les échecs plutôt que de supposer une synchronisation parfaite.
Générateur d'expressions Cron
Hippotool développe un générateur interactif d'expressions cron qui complétera ce guide. Dès son lancement, vous pourrez créer ou copier une planification, sélectionner la plateforme cible, lire une explication en langage clair et prévisualiser les prochaines exécutions planifiées. En attendant, consultez notre [lien/documentation]. terrain de jeu frontend prévisualisation HTML/CSS et Javascript en direct.
Les fonctions prévues pour l'outil correspondent directement aux erreurs mentionnées ci-dessus :
- Le mode Unix/Linux par défaut utilise cinq champs ; le dialecte le plus sûr est donc le point de départ.
- Un sélecteur de plateforme et de dialecte prenant en charge Linux crontab, Kubernetes CronJob, Vercel, GitHub Actions et Quartz.
- Un générateur/constructeur pour ceux qui préfèrent les listes déroulantes à la syntaxe brute
- Un analyseur syntaxique et un traducteur en langage clair pour les expressions que vous avez héritées d'une autre personne.
- Voici les 10 prochaines exécutions, pour que vous puissiez vérifier visuellement la cohérence du planning.
- Un sélecteur de fuseau horaire IANA, avec UTC comme option explicite.
- Un bouton de copie pour des horaires de copier-coller propres
- Erreurs de validation indiquant le champ incriminé
- Avertissement de non-concordance du nombre de champs lorsqu'une expression à six champs rencontre une cible à cinq champs
- Un avertissement jour du mois/jour de la semaine expliquant le comportement de correspondance « soit/soit ».
- Avertissements spécifiques à la plateforme, tels que la planification en UTC uniquement ou les alias de noms non pris en charge
- Aucune conversion silencieuse entre les formats Unix/Linux et Quartz, car une réécriture silencieuse masque les véritables différences sémantiques.
Avant sa mise en production, validez les expressions à l'aide des outils et de la documentation de votre planificateur, et confirmez le comportement avec une tâche de test inoffensive.
Foire aux questions
Qu'est-ce qu'une expression cron ?
Une expression cron est une chaîne de caractères qui indique au planificateur quand exécuter une tâche récurrente. Sous Unix et Linux, elle comporte cinq champs : minute, heure, jour du mois, mois et jour de la semaine. Dans le crontab d'un utilisateur, la commande à exécuter suit ces cinq champs. Le nombre de champs et les règles varient selon les planificateurs.
Que signifie * * * * * signifier?
texte* * * * *
Chaque champ est libre, ce qui permet de programmer l'exécution à chaque minute, chaque heure, chaque jour, chaque mois. En pratique, la tâche s'exécute toutes les minutes, car cron sous Linux vérifie ses entrées à chaque minute. Utilisez cette méthode uniquement pour des tâches courtes, peu coûteuses et compatibles avec les chevauchements. Certaines plateformes refusent les exécutions à la minute ; GitHub Actions n'autorise pas une exécution inférieure à 5 minutes.
Comment exécuter une tâche cron toutes les 5 minutes ?
texte*/5 * * * *
Le / L'opérateur « pas » dans le champ « minute » sélectionne les minutes 0, 5, 10, et ainsi de suite jusqu'à 55. Il s'agit d'une sélection basée sur l'horloge, et non sur les intervalles : si une séquence dure sept minutes, la séquence suivante commence toujours sur la grille de cinq minutes et peut se chevaucher. Ajoutez un verrou tel que : troupeau si le chevauchement pouvait poser problème.
Comment exécuter une tâche cron toutes les heures ?
texte0 * * * *
Ce déclencheur s'active au début de chaque heure. Pour répartir la charge au-delà de la minute 0, choisissez une autre minute, par exemple : 17 * * * * pendant 17 minutes après chaque heure. Pour un intervalle de plusieurs heures, utilisez un pas dans le champ horaire : 0 */4 * * * Les programmes s'exécutent à 00h00, 04h00, 08h00, 12h00, 16h00 et 20h00 dans le fuseau horaire du planificateur.
Comment programmer une tâche cron qui s'exécute chaque jour à une heure précise ?
Indiquez la minute et l'heure exactes dans les deux premiers champs et laissez les autres champs vides. *. Par exemple, 30 6 * * * il a lieu tous les jours à 6h30 (6h30 du matin), et 45 23 * * * Le programme s'exécute quotidiennement à 23h45. L'heure affichée est comprise entre 0 et 23. Veuillez vérifier le fuseau horaire utilisé par le planificateur avant de vous fier à l'heure affichée.
Comment programmer une tâche cron en semaine ?
texte0 9 * * 1-5
La gamme 1-5 Le champ « jour de la semaine » couvre les jours de la semaine du lundi au vendredi, soit 9 h 00 en semaine. POSIX numérote ce champ de 0 à 6, 0 représentant le dimanche. De nombreuses distributions Linux acceptent également les noms et la valeur 7 pour le dimanche. Quartz, quant à lui, numérote les jours de la semaine de 1 à 7 ; par conséquent, des chiffres identiques peuvent correspondre à des jours différents.
Quelle est la différence entre un cron à cinq champs et un cron à six champs ?
Le format standard Unix/Linux pour les tâches cron à cinq champs est : minute, heure, jour du mois, mois, jour de la semaine. Les variantes à six champs ajoutent une unité supplémentaire. Quartz place les secondes en premier et propose un septième champ optionnel : l’année. @Programmé Commence également par les secondes. AWS EventBridge Scheduler utilise six champs, le troisième représentant l'année. Le nombre de champs n'est pas interchangeable.
Pourquoi ma tâche cron s'exécute-t-elle au mauvais moment ?
La cause la plus fréquente est un problème de fuseau horaire. L'expression ne comporte pas de fuseau horaire propre ; elle peut donc être évaluée en heure locale du serveur, en heure par défaut de la plateforme (comme UTC) ou en heure définie explicitement. Le passage à l'heure d'été ou à l'heure d'hiver ajoute une heure de décalage ou entraîne l'annulation d'une exécution. Les délais de la plateforme constituent une autre cause : les exécutions planifiées peuvent être reportées en cas de forte charge.
Comment fonctionnent les fuseaux horaires de cron ?
C'est le planificateur qui décide, pas l'expression. Sous Linux, cron utilise l'heure de l'hôte et certaines implémentations respectent une certaine contrainte de temps. CRON_TZ Variable par crontab. Lectures Kubernetes .spec.timeZone. GitHub Actions utilise par défaut le fuseau horaire UTC, avec une option permettant d'en choisir un autre. fuseau horaire Valeur. Vercel est toujours en UTC. Définissez explicitement le fuseau horaire lorsque c'est possible et prévisualisez les prochaines exécutions.
Puis-je utiliser la syntaxe cron dans Kubernetes ?
Oui, avec quelques réserves. Une tâche CronJob Kubernetes utilise un calendrier à cinq champs. .spec.schedule, prend en charge les valeurs de pas Vixie, accepte les macros telles que @mensuel, et des friandises ? comme *. Le fuseau horaire appartient à .spec.timeZone, et en mettant TZ ou CRON_TZ Une erreur de validation se produit si la chaîne de planification est incorrecte. Concevez les tâches de manière à ce qu'elles soient idempotentes, car des doublons sont possibles.
Puis-je utiliser la même expression cron dans Vercel et Linux ?
Parfois, mais ne le tenez pas pour acquis. Vercel utilise cinq champs numériques et rejette les alias tels que LUN et JAN, nécessite * Dans un champ de jour, l'autre est défini, et l'horaire est toujours interprété en UTC. Une ligne crontab Linux utilisant des noms, les deux champs de jour ou l'heure locale du serveur ne sera pas convertie correctement. Vérifiez l'heure après toute conversion UTC.
Qu'est-ce qu'une expression Quartz cron ?
Quartz utilise un dialecte étendu de six ou sept champs séparés par des espaces : secondes, minutes, heures, jour du mois, mois, jour de la semaine et une année facultative. Il définit ses propres jetons, notamment ? pour “ sans valeur spécifique ”, plus L, W, et # dans les champs de jour, et les chiffres du jour de la semaine de 1 à 7. Les expressions Quartz ne peuvent pas être collées dans une crontab Unix/Linux.
Comment valider une expression cron avant de l'utiliser ?
Procédez en trois étapes. Premièrement, comptez les champs et vérifiez qu'ils correspondent au format documenté de votre planificateur. Deuxièmement, générez un aperçu de la prochaine exécution et comparez les dates et heures avec vos attentes, en tenant compte du fuseau horaire. Troisièmement, exécutez la planification avec une commande de test qui se contente d'écrire un horodatage dans un journal, vérifiez les entrées du journal, puis remplacez la commande par la commande réelle.
Conclusion finale
Identifiez le planificateur et son dialecte, indiquez le nombre de champs correct, puis vérifiez le fuseau horaire que la planification utilisera. Prévisualisez les prochaines exécutions et effectuez un déploiement à l'aide d'une commande sans risque avant d'associer des éléments importants à la planification.