L'expression de cron la plus chère que j'ai jamais écrite était 0 0 * * 0. Il a envoyé un e-mail hebdomadaire pour un Laravel Saas que je construisais, et j'étais absolument certain que cela signifiait "minuit le dernier jour de la semaine. Cela signifie minuit le dimanche. Mon modèle mental a déclaré que la semaine s'était terminée samedi. Pendant cinq semaines, les clients ont reçu leur "semaine en revue" un jour de retard, et personne dans l'équipe ne l'a attrapé parce que personne dans l'équipe ne pouvait lire Cron non plus - nous avons tous simplement plissé les yeux sur les cinq champs et avons hoché la tête.
C'est le sale secret de la syntaxe cron : presque tous ceux qui l'écrivent correspondent à une expression précédente dont ils se souviennent à moitié. Le format est vieux de plus de quarante ans, suffisamment dense pour qu'un seul caractère change complètement le calendrier et échoue en silence. Il n'y a pas d'erreur de compilateur pour "la mauvaise journée". Le travail s'exécute juste le mauvais jour, pour toujours, jusqu'à ce que quelqu'un le remarque.
un Analyseur d'expression cron comble cet écart. Vous collez l'expression et vous indique en anglais simple ce qui va réellement se passer. 0 0 * * 0 Revient comme "à 00:00, le dimanche" - plus lorsque les prochaines courses se déclencheront. Cette étape de lecture est la différence entre l'expédition d'un calendrier et l'expédition d'une supposition. J'ai construit celui sur toolz.dev parce que j'en avais assez du passage du contexte à un terminal, et parce que le désordre wp-cron que j'ai traité pendant des années dans WP Adminify m'a appris que la planification des bogues est le plus patient des bugs dans les logiciels.
Ce guide explique comment utiliser l'analyseur, comment fonctionnent réellement les cinq champs (y compris les deux bizarreries qui causent la plupart des incidents de production) et où la syntaxe cron diffère entre Crontab, GitHub Actions, Quartz et Laravel.
tl;dr : Collez toute expression crontab dans le Parseur cron toolz.dev Et obtenez une traduction en anglais simple et des temps d'exécution à venir - instantanément, côté client, pas d'inscription. Avant de déployer un calendrier, vérifiez toujours deux choses : la numérotation du jour de la semaine (0 et 7 est les deux dimanches) et le fuseau horaire dans lequel le planificateur s'exécute (les actions GitHub sont toujours UTC). associez-le à la Convertisseur d'horodatage Lorsque vous devez traduire ces temps de prochaine exécution dans les zones, et le Calculateur de différence de date aux intervalles de contrôle de santé mentale.
Principales caractéristiques
Traduction en anglais simple
Le travail de base de l'analyseur est de tourner */15 9-17 * * 1-5 Dans "toutes les 15 minutes, toutes les heures 9, 10, 11, 12, 13, 14, 15, 16 et 17, le lundi, mardi, mercredi, jeudi et vendredi." C'est verbeux - il énumère plutôt que de s'effondrer "9 à 17" dans une fourchette - et cette verbosité est le point. L'énumération est sans ambiguïté, une fourchette résumée est une autre chance de mal interpréter. La phrase est quelque chose que vous pouvez coller dans une description de demande d'extraction, lire à haute voix dans un stand-up ou montrer une partie prenante non technique. L'expression brute ne l'est pas. D'après mon expérience, la traduction compte le plus lors de la revue de code : un examinateur qui tamponnera cinq champs cryptés sur le caoutchouc attrapera immédiatement "attendre, pourquoi l'heure 17 apparaît-elle alors que le travail est censé s'arrêter à 17 h ?" lorsque chaque heure est énoncée. La traduction rend le calendrier falsifiable, ce qui est exactement ce à quoi la syntaxe Cron brute échoue.
Prévisualisation de la prochaine
Savoir quelle expression ressources est la moitié du problème ; savoir quand il Les incendies Suivant est l'autre moitié. L'analyseur calcule les cinq prochains temps d'exécution afin que vous puissiez les regarder contre votre intention. C'est là que surgissent des erreurs subtiles - une expression qui se lit très bien en anglais mais qui produit une prochaine série de "27 jours", car vous avez confondu le jour du mois avec le mois, ou une qui se déclenche à 03h00 ce soir, alors que vous vouliez dire 03h00 après le week-end. Je vérifie la liste de la prochaine diffusion à chaque fois, même pour les expressions dont je suis confiant. Surtout pour les expressions dont je suis confiant - voir l'anecdote d'ouverture.
Deux détails sur la façon dont ces temps sont calculés. Premièrement, ils sont évalués dans Le fuseau horaire local de votre navigateur, pas UTC et pas la zone de votre serveur - chaque exécution est affichée deux fois, une fois comme horodatage local et une fois comme équivalent UTC, afin que vous puissiez lire la cible de votre déploiement. Deuxièmement, lorsque le jour du mois et le jour de la semaine sont limités, l'analyseur applique des véritables cron ou de la sémantique plutôt que : 0 0 1 * 1 Incendie le 1er du mois et Tous les lundis, pas seulement les lundis qui tombent le 1er. Cette règle trébuche des personnes expérimentées, et voir cinq dates concrètes rend évidente d'une manière que la phrase ne le fait jamais.
Un aspect brut : une expression impossible comme 0 0 30 2 * (30 février) Analyse comme valide, se décrit heureusement comme "à 00:00, le jour du 30 mois, en février", puis affiche une liste vide des prochains tirages. Vide signifie jamais. C'est correct, mais c'est calme - un "cet horaire ne se déclenchera jamais" est l'amélioration évidente et je ne l'ai pas encore construit.
Répartition champ par champ
L'analyseur divise l'expression en cinq composantes - minute, heure, jour du mois, mois, jour de la semaine - et montre ce que chacun contribue. Cela compte car les erreurs cron sont presque toujours un problème à un seul champ : la bonne valeur dans la mauvaise colonne. 0 12 * * * (midi tous les jours) et 12 0 * * * (12h12 tous les jours... Non, 00:12 par jour) sont un échange à part. Voir "Heure : 0" explicitement étiqueté est la façon dont vous attrapez cet échange en deux secondes au lieu de deux semaines.
Prise en charge des plages, étapes et listes
Les expressions du monde réel s'appuient sur la syntaxe de l'opérateur : 1-5 gammes, */10 étapes, 1,15 Listes et combinaisons comme 0 8-18/2 * * 1,3,5. L'analyseur gère tout, y compris les formes combinées qui déclenchent des lecteurs humains. Valeurs de pas sur les plages — 8-18/2 Signification "toutes les 2 heures de 8 à 18" - sont légales, utiles et presque illisibles sans outillage. Si vous avez déjà hérité d'un Crontab rempli d'un administrateur système, vous savez pourquoi cette fonctionnalité existe.
Validation stricte de cinq champs (y compris ce qu'il n'acceptera pas)
L'analyseur prend des expressions standard à cinq champs et rien d'autre. coller @daily Et vous obtenez une erreur - "5 champs attendus (minutes jour-de-mois jour-de-semaine), obtenu 1" - pas une traduction. Idem pour @hourly, @weekly, et @reboot. C'est un véritable écart plutôt qu'un principe de conception, et je préfère le dire plutôt que de vous laisser découvrir à mi-débug; les macros de sténographie sont suffisamment courantes dans les crontabs réels pour qu'ils appartiennent à l'outil. Jusqu'à ce qu'ils soient, traduisez manuellement : @hourly est 0 * * * *, @daily est 0 0 * * *, @weekly est 0 0 * * 0, @monthly est 0 0 1 * *, @yearly est 0 0 1 1 *. @reboot N'a pas du tout un équivalent de cinq champs - ce n'est pas un calendrier, il fonctionne une fois au démarrage de Daemon, un fait qui a surpris de nombreuses personnes exécutant des migrations depuis Crontab.
La rigueur est payante ailleurs. Une expression de quartz à six champs est rejetée avec un nombre de champs au lieu d'être lue en silence. Les valeurs hors plage nomment le champ et la plage légale (Value 25 out of range for hour (allowed 0-23)). Plages inversées comme 5-1 sont pris. Et il accepte les choses que contient les vrais crontabs : noms de mois et de jours (JAN, SUN), 7 Comme une deuxième orthographe de dimanche et la Vixie 5/15 Forme signifiant "tous les 15 à partir de 5". A savoir pendant que vous traduisez ces macros à la main : chaque @daily Le travail sur un serveur se déclenche au même instant - minuit - donc quarante d'entre eux sont un pic de charge nocturne. Je disperse le mien en quelques minutes (17 3 * * *, 43 4 * * *) pour cette raison.
Traitement côté client
L'analyseur s'exécute entièrement dans votre navigateur. Rien de ce que vous collez n'est téléchargé, enregistré ou stocké. Cela ressemble à un langage de confidentialité du passe-partout jusqu'à ce que vous vous souveniez de ce que contiennent réellement les cronabs : votre calendrier de sauvegarde, votre timing de la facturation, la minute exacte où votre sécurité s'explose. La planification de l'infrastructure est une donnée de reconnaissance. Le garder hors des serveurs d'autres personnes n'est pas paranoïaque, cela ne crée tout simplement pas de problème là où il n'en faut pas.
Comment utiliser l'analyseur cron
Étape 1 : Collez ou tapez votre expression
Ouvrez le analyseur et déposez l'expression — à partir d'un fichier crontab, un schedule: Bloquer dans un workflow d'actions GitHub, un manifeste CronJob de Kubernetes ou un Laravel ->cron() appeler. La syntaxe standard à cinq champs fonctionne telle quelle ; @daily Et ses frères et sœurs ne le font pas, alors étendez-les en premier. puis frappez parse. Si vous partez de zéro plutôt que de décoder, les boutons prédéfinis (chaque minute, heure, tous les jours à minuit, 9h00, 1er du mois) chargent une expression de travail, vous pouvez modifier champ par champ, réanalyser au fur et à mesure.
Étape 2 : Relisez la traduction
C'est le pas que les gens sautent et ne devraient pas. Lisez la sortie en anglais simple et comparez-la à la phrase dans votre tête. Si vous avez écrit l'expression "entendu tous les lundis à 9 h" et la lecture dit "à 09:00 le jour du mois 1 - - félicitations, vous venez de voir l'échange de colonnes classique avant la production. La lecture est votre test unitaire.
Étape 3 : Vérifiez les prochains temps d'exécution
Vérifiez les cinq exécutions à venir. Les dates atteignent-elles que vous attendez ? La première série est-elle ce soir, demain ou le mois prochain ? Faites attention à l'écart entre les courses - un mal placé */ L'étape transforme "toutes les 6 heures" en "toutes les minutes de chaque 6 heure" (* */6 * * * VS 0 */6 * * *), et cinq courses à une minute d'intervalle au lieu de six heures d'intervalle, c'est difficile à manquer. Une liste vide signifie que le calendrier ne peut jamais se déclencher.
Étape 4 : Comptez le fuseau horaire avant le déploiement
L'analyseur vous dit alors que par rapport à une horloge ; votre planificateur décide dont Horloge. Avant de déployer, confirmez le fuseau horaire utilisé par le système d'exécution. Actions GitHub : Toujours UTC, aucune exception. Serveurs : quel que soit le système d'exploitation défini, fréquemment UTC sur les boîtes cloud. Laravel : votre fuseau horaire de l'application, à moins que vous ne vous enchaîniez ->timezone(). Traduisez une prochaine fois à travers le Convertisseur d'horodatage Si vous avez besoin de le voir dans votre zone locale ou dans votre zone locale ou dans votre client.
Plongée approfondie technique : comment fonctionnent les expressions cron
Le format à cinq champs provient d'Unix Cron, standardisé en pratique par la mise en œuvre de Cron de Paul Vixie à la fin des années 1980, celui documenté dans crontab(5) Et toujours expédié, sous forme descendante, sur la plupart des systèmes Linux aujourd'hui. Les champs, de gauche à droite :
| champ de courses | Valeurs autorisées | notes |
|---|---|---|
| moment | 0–59 | |
| heure | 0–23 | Horloge 24 heures, 0 est minuit |
| jour du mois | 1–31 | Méfiez-vous des mois sans 31e |
| mois | 1–12 ou janvier–décembre | Noms autorisés dans Vixie Cron |
| jour de la semaine | 0–7 ou soleil–sam | 0 et 7 sont les deux dimanche |
Chaque champ accepte * (toute valeur), listes (1,15), plages (1-5), et les étapes (*/10 ou 20-59/5). C'est toute la grammaire. La complexité n'est pas dans la syntaxe - c'est dans trois bizarreries comportementales.
Quirk One : le zéro jour de la semaine. selon crontab(5), à la fois 0 et 7 dimanche signifient. Certaines implémentations plus anciennes ou plus strictes acceptent uniquement 0. Quartz — le planificateur Java utilisé par Jenkins et la moitié des logiciels d'entreprise — Nombres jours 1 à 7 à partir de dimanche, donc Quartz 2 est lundi tandis que Crontab's 2 c'est mardi. Si vous migrez des horaires entre les systèmes, ce hors-par-un est à l'affût. Analysez toujours, ne transcriez jamais.
Bilan 2 : jour du mois ou jour de la semaine. Voici celui que presque personne ne sait jusqu'à ce qu'il les mordille. alors que l'un et Les champs du jour du mois et du jour de la semaine sont limités (ni les champs *), Vixie Cron exécute le travail lorsque n'importe lequel Matchs - un ou, pas un et. aussi 0 0 13 * 5 Cela ne signifie pas "Vendredi 13. Cela signifie "tous les 13 du mois et tous les vendredis". crontab(5) Et c'est profondément contre-intuitif. Si vous avez vraiment besoin de "Vendredi 13", vous avez besoin d'une vérification de date côté script ou d'un planificateur avec une syntaxe plus riche.
Bilan trois : fuseaux horaires et DST. Cron n'a pas de champ de fuseau horaire. L'expression est interprétée dans l'heure locale de l'ordonnanceur, quel qu'il soit. Deux conséquences concrètes :
- Les actions GitHub s'exécutent
schedule:Déclencheurs dans UTC, arrêt complet. Un flux de travail programmé à0 9 * * *Incendie à 9 h 00 – 4 ou 5 heures du matin à New York selon la saison, car l'UTC n'observe pas l'heure de l'heure, mais l'horloge de votre public visé le fait. Votre rapport quotidien "9 AM" se dérive d'une heure deux fois par an, à moins que vous n'ajustez le flux de travail ou que vous ne le gérez dans le code. - Sur les serveurs définis sur une zone d'observation DST, une nuit par an, la 02h00-03h00 n'existe pas, et une nuit, cela se produit deux fois. Un travail planifié à 02h30 est soit sauté soit double-feu selon la mise en œuvre. Correction ennuyeuse et correcte : planifiez les travaux critiques en dehors de 01h00 à 03h00 ou exécutez des serveurs sur UTC. Je fais les deux.
Formats étendus. Le quartz utilise six ou sept champs (un champ de seconde en tête et une année de suivi facultative), ainsi que des opérateurs supplémentaires comme L (dernier), W (le jour de la semaine le plus proche), et # (nème semaine du mois). Certains crons prennent également en charge un champ de seconde en tête. Si votre expression a six champs et que vous n'êtes pas sûr de quel dialecte il s'agit, collez-le dans l'analyseur - une expression à six champs interprétée comme cinq champs produira une sortie visiblement erronée, qui est elle-même diagnostique. et @reboot, le canard étrange des chaînes spéciales, n'est pas du tout un calendrier : il s'exécute une fois au démarrage de Daemon, ce qui signifie que, sur les systèmes modernes, "quand la boîte redémarre", un fait qui a surpris de nombreuses personnes exécutant des migrations de bases de données depuis Crontab.
Pour une visite plus large des utilitaires de développeur qui s'associent aux travaux de planification, le Guide des outils de codage Couvre toute la boîte à outils.
Cas d'utilisation courants
Déboguer une entrée de planificateur de Laravel
Le planificateur de Laravel enveloppe le cron dans les méthodes fluides - ->dailyAt('03:00'), ->weeklyOn(1, '8:00') — Mais la trappe d'évacuation, ->cron('*/5 * * * 1-5'), est la syntaxe brute de Crontab, et les horaires compliqués se retrouvent là-bas. Le système crontab s'exécute schedule:run Chaque minute, et Laravel décide en interne de ce qui est dû. Lorsqu'une commande planifiée ne déclenche pas, mon premier coup est de coller le ->cron() Chaîne dans l'analyseur pour confirmer que cela signifie ce que le commentaire au-dessus de celui-ci revendique. Environ la moitié du temps, ce n'est pas le cas. L'autre moitié, le bogue est le fuseau horaire : l'application est définie sur UTC tandis que le développeur a pris l'heure locale. L'analyseur résout le premier cas en secondes et pointe un doigt vers le second.
Démêler WP-Cron sur les sites WordPress
WordPress est livré avec WP-Cron, qui n'est pas du tout cron - c'est un pseudo-horaire que les visites de pages sur les pages, de sorte qu'un site à faible trafic peut s'exécuter à chaque demande. Au cours de mes années d'administration WP, cela a généré un flux constant de "postes programmées" ne publient pas de rapports. Le correctif standard désactive WP-Cron (DISABLE_WP_CRON) et déclenchement wp-cron.php à partir d'un vrai serveur crontab - à quel point vous écrivez des expressions cron réelles, généralement */5 * * * *, et l'analyseur gagne son contrôle de les vérifier. Si vous exécutez WordPress à n'importe quelle échelle, cette migration vaut la peine d'être faite cette semaine, pas un jour.
Vérification des calendriers d'actions GitHub
Les horaires des CI échouent tranquillement : une version nocturne qui arrête de fonctionner ne sert à personne. Lors de la rédaction d'un schedule: Trigger, j'analyse l'expression, regarde les temps d'exécution suivant, puis ajoute mentalement le décalage UTC. Deux détails supplémentaires spécifiques aux actions : les planifications ne s'exécutent que sur la branche par défaut et les exécutions peuvent être retardées ou supprimées pendant les périodes de charge élevée, ce qui le dit. Si le temps exact est important, les actions déclenchées par le cron sont le mauvais outil ; si le temps approximatif est fin, faites au moins le temps approximatif directement Temps approximatif.
Auditer un Crontab hérité
Chaque serveur de longue durée accumule un crontab écrit par des personnes qui n'y travaillent plus. administration crontab -l Et coller chaque ligne à travers l'analyseur est l'audit le plus rapide que je connaisse : dans les dix minutes, vous disposez d'un inventaire de calendrier en anglais simple, et vous trouverez presque toujours au moins un travail en faisant quelque chose dont personne ne s'en souvient - une sauvegarde s'exécutant deux fois, un script de nettoyage qui n'a jamais été égal le jour où il était censé le faire, un * * * * * ça aurait dû être 0 * * * * Marteler une API soixante fois par heure. Lors de la comparaison d'un ancien crontab avec un nouveau lors d'une migration, le Outil de diff de texte À côté de l'analyseur rend la revue mécanique.
Planification de Kubernetes Cronjobs
Les cronjobs K8S utilisent une syntaxe standard à cinq champs et, depuis 1,27, prennent en charge une timeZone Field — Une véritable amélioration par rapport à Cron classique. Le flux de travail de l'analyseur est le même : vérifiez l'expression, vérifiez les exécutions suivantes, puis confirmez startingDeadlineSeconds et concurrencyPolicy Couvrir les modes de défaillance que le CRON lui-même n'est pas. Une expression peut être parfaite et le travail s'accumule toujours si une exécution lente chevauche le déclencheur suivant; l'analyseur obtient le bon calendrier afin que vous puissiez plutôt consacrer votre attention à ces paramètres opérationnels.
Les dialectes cron comparés
| Vixie Cron / Crontab | Actions GitHub | quartz | Planificateur de Laravel | Minuteries systémiques | |
|---|---|---|---|---|---|
| champs | 5 | 5 | 6–7 (secondes, année) | 5 (via ->cron()) |
OnCalendar Syntaxe, pas cron |
| Numérotation du jour de la semaine | 0–7 (0 et 7 = soleil) | 0–6 (0 = soleil) | 1–7 (1 = soleil) | suit crontab | noms (Mon, Tue) |
| fuselage horaire | Système local | Toujours UTC | configurable | Fuseau horaire de l'application ou ->timezone() |
système local ou Timezone= |
| Chaînes spéciales | @daily, @reboot, etc. |
Non pris en charge | Non pris en charge | Méthodes fluides à la place | OnBootSec=, raccourcis du calendrier |
| seconde précision | non | Non (min ~5 min en pratique) | oui | Non (coche à la minute) | oui |
| le mieux pour | Emplois de serveur | Horaires CI/CD | Écosystèmes de JVM | Applications Laravel | Services Linux modernes |
Quand utiliser lequel : crontab pour les travaux de serveur simple, temporisateurs systemd lorsque vous souhaitez une gestion de la journalisation et des dépendances gratuitement sur Linux moderne, le planificateur de framework lorsque le travail vit dans votre application de toute façon, et des actions ne planifient que les tâches CI qui tolèrent un timing flou. Quel que soit votre choix, l'expression à cinq champs est la lingua franca - c'est pourquoi un analyseur qui parle couramment appartient à vos signets à côté du reste de votre Boîte à outils pour les développeurs Web.
FAQ
Qu'est-ce qu'un analyseur d'expression cron ?
Un analyseur d'expression cron est un outil qui lit la syntaxe cronab, comme */15 9-17 * * 1-5 — et le traduit en une description de calendrier en anglais simple, généralement à côté d'un aperçu des prochains temps d'exécution. Il vous permet de vérifier ce qu'un planning fait réellement avant de le déployer, au lieu de découvrir un champ mal lu lorsqu'un travail se déclenche au mauvais moment de la production.
Que signifient les cinq champs d'une expression cron ?
De gauche à droite : minute (0–59), heure (0–23), jour du mois (1–31), mois (1–12) et jour de la semaine (0–7, où 0 et 7 signifient le dimanche). Chaque champ accepte * Pour toute valeur, liste de virgules, plages de tiret, et / valeurs de pas. aussi 30 2 1 * * signifie 02h30 le premier jour de chaque mois.
Pourquoi mon travail cron fonctionne-t-il au mauvais moment ?
Les deux causes les plus courantes sont le fuseau horaire et la confusion sur le terrain. Cron s'exécute à l'heure locale du planificateur - les actions GitHub utilisent toujours UTC, et de nombreux serveurs cloud le font également - donc un travail planifié pour "9 AM" peut déclencher des heures de décrochage de votre horloge murale. L'autre classique est d'échanger des champs, comme mettre la valeur de l'heure dans la colonne Minute. L'analyse de l'expression et la vérification des temps d'exécution suivants attrapent les deux.
sont 0 et 7 dimanche à cron ?
Dans Vixie Cron et la plupart des implémentations Linux, oui — le crontab(5) La page de manuel permet à la fois 0 et 7 pour dimanche. Mais ce n'est pas universel : les nombres de quartz comptent les jours 1 à 7 à partir de dimanche et certains analyseurs stricts rejettent 7. Lors du déplacement d'expressions entre les systèmes, vérifiez à nouveau le champ du jour de la semaine plutôt que de supposer que la numérotation est reportée.
Qu'est-ce que 0 0 13 * 5 vraiment faire?
Non "Vendredi 13." Lorsque le jour du mois et le jour de la semaine sont limités, Standard Cron les traite comme un OR : le travail s'exécute le 13 m de mois. et Tous les vendredis. Ceci est un comportement de Vixie Cron documenté et l'une des règles les plus mal comprises du format. Si vous avez besoin d'un vrai et ajoutez une vérification de date dans le script lui-même.
Comment l'heure d'été affecte-t-elle les travaux de cron ?
Sur les serveurs dans les fuseaux horaires DST, les travaux planifiés entre 01h00 et 03h00, heure locale, peuvent sauter une course (lorsque les horloges sautent vers l'avant) ou s'exécuter deux fois (lorsqu'elles reculent), selon la mise en œuvre. Les modèles les plus sûrs sont les serveurs en cours d'exécution sur UTC ou la planification de travaux critiques en dehors de cette fenêtre. Notez que les ordonnanceurs basés sur UTC, comme les actions GitHub, ne sautent pas, mais l'heure locale correspond aux quarts de travail d'une heure deux fois par an.
est @daily comme 0 0 * * *?
Oui — @daily (et son synonyme @midnight) s'étend à exactement 0 0 * * * dans Vixie Cron. Deux mises en garde. Tout d'abord, l'analyseur Toolz.dev n'accepte que les expressions à cinq champs, alors collez 0 0 * * * plutôt que @daily Pour l'instant. Deuxièmement, chaque @daily Job se déclenche au même instant, de sorte qu'un serveur avec beaucoup d'entre eux obtient un pic de charge à minuit. Répartir les emplois quotidiens en quelques minutes et heures échelonnées évite ce troupeau de tonnerre auto-infligé.
L'analyseur cron toolz.dev télécharge-t-il mes expressions ?
non . Le analyseur S'exécute entièrement dans votre navigateur : les expressions sont analysées côté client et ne sont jamais envoyées sur un serveur, enregistrées ou stockées. Étant donné que les crontabs révèlent des détails opérationnels tels que la temporisation de sauvegarde et la facturation, les garder hors de serveurs tiers est une valeur par défaut raisonnable et vous pouvez confirmer le comportement vous-même dans l'onglet Réseau de votre navigateur.
Relisez-le avant de l'expédier
Cinq semaines d'e-mails de résumé arrivant avec un jour de retard n'est pas une panne dramatique. Personne ne m'a envoyé de pages. C'est exactement ce qui rend les bugs de planification coûteux : ils ne s'annoncent pas, ils font simplement la mauvaise chose jusqu'à ce qu'un client le mentionne en passant. L'habitude qui m'a fixé pour moi n'est pas une discipline ou un meilleur souvenir de l'ordre sur le terrain - c'est une lecture de trente secondes. Collez l'expression, lisez la phrase anglaise, regardez cinq dates concrètes, puis déployez.
Gardez le analyseur À côté des outils que vous rechercherez dans la même session de débogage : le Convertisseur d'horodatage Lorsqu'un temps d'exécution suivant doit passer d'une zone à l'autre (j'ai écrit le Traps d'horodatage Unix qui mord le plus dur), le Calculateur de différence de date pour les intervalles de contrôle de santé mentale, et le Outil de diff de texte Lorsque vous comparez un ancien Crontab à un nouveau lors d'une migration. le Guide des outils de codage Parcoure la façon dont l'ensemble s'emboîte et que tout fonctionne côté client - qui, pour un fichier qui documente exactement lorsque vos sauvegardes et votre facturation s'exécutent, sont la seule valeur par défaut raisonnable.
