Expression cron : lire la syntaxe et calculer les prochaines exécutions

Lisez une expression cron champ par champ, voyez ses prochaines exécutions en UTC ou en heure locale et évitez les pièges de pas, de fuseau et de dialecte.

16.10.2026

19 min de lecture

Partager cet article:

CronPlanificationFuseau horaireDevOpsTutoriel

Une expression cron se lit champ par champ et se vérifie sur des dates

Une ligne comme */15 9-17 * * 1-5 pilote une sauvegarde, un workflow CI ou un CronJob Kubernetes. Elle est courte et on la relit rarement. Un champ lu de travers, et la tâche part à la mauvaise heure, en double ou pas du tout. Le parseur cron accepte cinq champs (minute, heure, jour du mois, mois, jour de la semaine) ou six, avec les secondes en tête. Il accepte aussi les alias comme @daily et @hourly. Il affiche une phrase qui résume le planning et la valeur de chaque champ. Il donne aussi les 5, 10 ou 25 prochaines exécutions, en UTC ou dans le fuseau de votre navigateur. Le calcul se fait dans l’onglet et l’expression n’est envoyée à personne. Ce guide rappelle la syntaxe et les alias, puis montre comment lire le résultat. Viennent ensuite les pièges qui coûtent cher. Un pas ne tombe pas juste, deux champs de jour forment une alternative, une date n’existe pas, et le fuseau comme le changement d’heure du 25 octobre 2026 déplacent tout. Il compare enfin les dialectes de crontab, de Kubernetes, de GitHub Actions et d’AWS EventBridge, et refait les calculs en code. Les outils voisins se trouvent dans le hub des utilitaires développeur.

Cinq champs standard, ou six avec les secondes en tête. Minute de 0 à 59, heure de 0 à 23, jour du mois de 1 à 31, mois de 1 à 12 ou de JAN à DEC, jour de la semaine de 0 à 7 ou de SUN à SAT (0 et 7 valent dimanche)

Les listes (<code>1,15</code>), les plages (<code>9-17</code>) et les pas (<code>*/15</code>, <code>10-50/10</code>). Les noms de mois et de jours s’écrivent en majuscules ou en minuscules

Les alias <code>@hourly</code>, <code>@daily</code>, <code>@midnight</code>, <code>@weekly</code>, <code>@monthly</code>, <code>@yearly</code> et <code>@annually</code>, remplacés par leur forme à cinq champs dans la zone de saisie. <code>@reboot</code> est refusé

Une phrase de résumé pour les plannings courants (toutes les 15 minutes, tous les jours à 09:00, du lundi au vendredi), sinon le détail champ par champ

Les 5, 10 ou 25 prochaines exécutions, avec le délai avant la première, en UTC ou en heure locale du navigateur

Une note quand le jour du mois et le jour de la semaine sont tous deux fixés : l’un ou l’autre déclenche l’exécution

Aucun envoi : le calcul reste dans le navigateur

À quoi sert le parseur, et où il s’arrête

Les bons usages

Le parseur répond à une seule question : à quels instants cette expression se déclenche-t-elle ? Il permet de le vérifier avant de la déployer.

Relire la ligne d’un collègue ou d’un ancien crontab avant de la copier : la phrase de résumé d’abord, les cinq champs ensuite

Contrôler un pas. <code>*/7</code> ne répète pas la tâche toutes les 7 minutes (voir plus bas) et les prochaines exécutions le montrent

Contrôler une fin de mois comme <code>0 0 31 * *</code>, qui saute les mois de 30 jours. Demandez 25 exécutions pour voir le motif

Lire le planning dans votre fuseau en passant l’affichage sur Local, en sachant que le calcul reste en UTC (voir les erreurs plus bas)

Écrire un alias sous sa forme à cinq champs avant de le coller dans un outil qui n’accepte aucune macro, comme GitHub Actions

Copier la description ou la liste des exécutions dans un ticket ou une revue de code, pour que le relecteur voie les dates en plus de la ligne

Ce qui relève d’autre chose

Le parseur calcule des dates. Le reste de la chaîne se contrôle ailleurs.

Convertir l’epoch d’un journal ou d’un token en date lisible : le <a href="/fr/unix-timestamp" class="text-primary hover:underline">convertisseur de timestamp Unix</a>

Vérifier qu’un manifeste Kubernetes est bien formé : le <a href="/fr/validate-kubernetes" class="text-primary hover:underline">validateur Kubernetes</a>, présenté dans le <a href="/fr/blog/kubernetes-valider-manifests-yaml" class="text-primary hover:underline">guide Kubernetes</a>

Vérifier qu’un workflow GitHub Actions est bien formé : le <a href="/fr/validate-github-actions" class="text-primary hover:underline">validateur GitHub Actions</a>, présenté dans le <a href="/fr/blog/github-actions-linter-workflow-yaml" class="text-primary hover:underline">guide GitHub Actions</a>. Le <a href="/fr/blog/gitlab-ci-formater-valider-yaml" class="text-primary hover:underline">guide GitLab CI</a> fait de même pour <code>.gitlab-ci.yml</code>

Tester la tâche elle-même : le parseur ne lance rien, ne lit aucun journal et ignore si la machine était allumée

Surveiller l’exécution réelle : un planning juste ne prouve pas que la tâche a tourné. Il faut des journaux, une alerte ou un contrôle du dernier succès

Lire les particularités d’un dialecte : le parseur ne connaît ni <code>?</code>, ni <code>L</code>, <code>W</code> et <code>#</code>, ni le champ année

Planifier une exécution unique : cron répète, il ne dit pas « une seule fois ». Utilisez <code>at</code> pour cela

Lire les résultats sans se tromper

Le résultat, champ par champ

Saisissez l’expression dans le parseur cron. Les dates ci-dessous partent du vendredi 16 octobre 2026 à 12:00 UTC. L’outil part de l’instant présent : vos dates seront donc d’autres.

<code>0 9 * * 1-5</code> donne la phrase « À 09:00 du lundi au vendredi ». Les prochaines exécutions sont les lundi 19, mardi 20, mercredi 21, jeudi 22 et vendredi 23 octobre à 09:00 UTC

<code>*/15 9-17 * * 1-5</code> n’a pas de phrase exacte. L’outil écrit « Détail du planning », ajoute une note, puis donne les cinq champs et les exécutions : le vendredi 16 à 12:15, 12:30, 12:45, 13:00 et 13:15

Le dernier départ de la journée pour <code>9-17</code> avec <code>*/15</code> est 17:45. La plage d’heures inclut toute l’heure 17, jusqu’à 17:59

Les cinq cases reprennent chaque champ tel que vous l’avez écrit. Seuls les alias sont développés : <code>@daily</code> devient <code>0 0 * * *</code> dans la zone de saisie

Le jour de la semaine accepte 0 et 7 pour dimanche. <code>0 0 * * 7</code> et <code>0 0 * * 0</code> donnent les mêmes dates

La mention « Prochaine » donne le délai avant la première exécution, ce qui suffit à repérer une expression qui ne part que dans six mois

Un pas ne se compte pas depuis la dernière exécution

Un pas se calcule à l’intérieur de la plage du champ. À chaque début de plage, le compteur repart de zéro.

<code>*/7 * * * *</code> se déclenche aux minutes 0, 7, 14 et ainsi de suite jusqu’à 56, puis revient à la minute 0 : 12:49, 12:56, puis 13:00, soit 4 minutes plus tard. La page de manuel de crontab donne le même cas avec <code>*/35</code>

<code>0 */5 * * *</code> tombe à 0, 5, 10, 15 et 20 heures. Après 20:00 vient 00:00 : l’écart est de 4 heures et non de 5 heures

<code>0 0 */2 * *</code> vise les jours 1, 3, 5 jusqu’à 31. Le 31 octobre est suivi du 1er novembre, soit deux jours de suite

Pour un vrai « toutes les N unités », prenez un N qui divise 60 pour les minutes ou 24 pour les heures, ou comptez dans le script à partir de l’heure du dernier succès

Un pas sur une valeur seule, comme <code>20/15</code>, part de cette valeur et va jusqu’au maximum du champ : minutes 20, 35 et 50

Quand jour du mois et jour de la semaine se combinent

Quand les deux champs sont renseignés, cron ne les combine pas en ET. Il lance la tâche si l’un ou l’autre correspond, selon la page de manuel de crontab. L’outil le signale par une note sous la phrase de résumé.

<code>0 0 1 * 1</code> se déclenche le 1er du mois et chaque lundi. Les prochaines exécutions sont les lundis 19 et 26 octobre, le dimanche 1er novembre, puis les lundis 2 et 9 novembre

Le premier lundi du mois n’existe pas en cron standard. Écrire <code>1-7</code> pour le jour du mois et <code>1</code> pour le lundi donne une alternative, donc trop d’exécutions

Contournement : planifier chaque lundi et tester la date dans la commande, avec <code>[ "$(date +\%d)" -le 7 ]</code>. Dans une crontab, le signe % s’écrit <code>\%</code>

Quand l’un des deux champs vaut <code>*</code>, l’autre décide seul : <code>0 9 * * 1-5</code> n’a pas de OU

Les dates absentes du calendrier

Une expression valide peut ne jamais se déclencher. L’outil cherche sur environ deux ans et le dit.

<code>0 0 30 2 *</code> vise un 30 février : aucune exécution. L’outil affiche « Aucune exécution trouvée dans la fenêtre de recherche »

<code>0 0 31 * *</code> ne part que les mois de 31 jours. Depuis le 16 octobre 2026 : les 31 octobre et 31 décembre 2026, puis les 31 janvier, 31 mars, 31 mai, 31 juillet et 31 août 2027

<code>0 0 29 2 *</code> n’a qu’une date dans la fenêtre, le 29 février 2028. L’outil affiche « Résultats partiels avant la limite de recherche », ce qui est normal : la suivante tombe en 2032

Le dernier jour du mois n’a pas d’écriture en cron standard. Planifiez du 28 au 31 et testez le lendemain dans la commande, par exemple avec <code>[ "$(date -d tomorrow +\%d)" = 01 ]</code> (avec GNU <code>date</code>)

Quatre erreurs qu’on ne voit qu’en production

Croire que l’affichage Local change le fuseau du planning

Le parseur calcule toujours en UTC. L’option Local ne change que l’écriture des dates trouvées. 0 9 * * * donne 09:00 UTC, que l’outil écrit 11:00 sur un navigateur réglé sur Paris le 16 octobre 2026. Un cron lancé sur un serveur réglé sur Paris se déclenche à 09:00 heure de Paris, c’est-à-dire 07:00 UTC jusqu’au 24 octobre et 08:00 UTC ensuite. Le fuseau qui s’applique dépend du système qui exécute. Le démon cron suit le fuseau de la machine. Un CronJob Kubernetes suit celui du kube-controller-manager, sauf si .spec.timeZone est renseigné. GitHub Actions compte en UTC par défaut.

Lire l’heure affichée en Local comme l’heure à laquelle la tâche tournera sur le serveur

Oublier que le serveur, le conteneur et votre poste n’ont pas forcément le même fuseau

Écrire une heure locale dans un système qui compte en UTC

Mettre <code>CRON_TZ</code> ou <code>TZ</code> dans le champ <code>schedule</code> d’un CronJob : Kubernetes refuse la ressource, car le fuseau relève de <code>.spec.timeZone</code> et non de ce champ

Décidez du fuseau avant d’écrire l’heure. Pour vérifier un planning exprimé en heure locale, convertissez l’heure en UTC à la main et lisez les dates en UTC.

Laisser une heure fixe traverser un changement d’heure

L’Europe passe à l’heure d’hiver le dimanche 25 octobre 2026. À 03:00 heure d’été, il est de nouveau 02:00. Les États-Unis changent une semaine plus tard, le 1er novembre. Une tâche fixée à 30 2 * * * rencontre alors une heure qui existe deux fois au retour à l’heure d’hiver, ou pas du tout au passage à l’heure d’été. Les implémentations ne s’accordent pas. La page de manuel Debian de cron(8) indique que les tâches de l’heure sautée partent peu après le changement et que celles de l’heure répétée ne sont pas relancées. La page crontab(5) publiée sur man7.org écrit le contraire. Une heure qui n’existe pas ne correspond jamais, et une heure répétée déclenche deux fois. GitHub Actions, avec la clé timezone, avance une exécution tombée dans l’heure sautée jusqu’à la prochaine heure valide.

Placer une tâche importante entre 01:00 et 04:00 heure locale

Supposer qu’une tâche quotidienne tourne exactement 24 heures après la précédente

Compter sur un seul départ alors que l’heure peut être jouée deux fois ou pas du tout

Écrire une tâche qui ne supporte pas d’être lancée deux fois

Planifiez en UTC quand vous le pouvez, sinon à une heure qui existe toujours, comme 05:00, et écrivez des tâches qu’on peut relancer sans dégât.

Coller une expression d’un autre dialecte

Le même planning s’écrit différemment selon l’outil. AWS EventBridge ajoute un champ année et exige un ? dans l’un des deux champs de jour. Quartz et Spring placent les secondes en premier. Le parseur refuse ce qu’il ne connaît pas et nomme le champ et le jeton en cause, par exemple « Valeur invalide dans Jour du mois (?) ».

Coller <code>0 0 ? * MON-FRI *</code> d’EventBridge : six champs alors que le réglage est sur cinq, et un <code>?</code> que l’outil ne lit pas. <code>L</code>, <code>W</code> et <code>#</code> sont refusés de la même façon

Écrire une plage qui passe minuit, comme <code>22-2</code> : le début dépasse la fin et l’outil la refuse. Écrivez <code>22-23,0-2</code>

Passer en six champs, y mettre des secondes non nulles, puis revenir à cinq : le retour est refusé tant que les secondes ne valent pas 0

Taper un alias hors liste, comme <code>@reboot</code> ou <code>@every5m</code>, ou en mettre un dans GitHub Actions, qui n’en accepte aucun

Notez le dialecte de la cible avant de copier une expression, puis convertissez à la main les jours, l’année et les secondes. Gardez dans le parseur la forme à cinq champs.

Valider le planning et oublier l’exécution

Une expression juste ne garantit ni que la tâche part, ni qu’elle part une seule fois. La documentation de Kubernetes prévient que la création d’un Job est approximative : deux Jobs peuvent être créés, ou aucun, et les tâches doivent donc être idempotentes. La politique de concurrence par défaut est Allow, qui laisse démarrer une exécution pendant que la précédente tourne. Si le contrôleur compte plus de 100 départs manqués, il ne lance plus la tâche et journalise une erreur. GitHub Actions retarde les exécutions planifiées aux heures de forte charge, surtout au début de chaque heure, et peut en abandonner. Dans un dépôt public, les workflows planifiés sont désactivés après 60 jours sans activité.

Planifier <code>0 * * * *</code> sur GitHub Actions, où le début de l’heure est le moment le plus chargé

Laisser <code>concurrencyPolicy: Allow</code> pour une tâche plus longue que son intervalle

Ne pas fixer <code>startingDeadlineSeconds</code> et se retrouver, après une panne du contrôleur, avec plus de 100 départs manqués et plus aucune exécution

Compter sur un workflow planifié dans un dépôt public qui ne reçoit plus de commit

Choisissez une minute décalée comme <code>17 * * * *</code>, fixez <code>concurrencyPolicy: Forbid</code> quand deux exécutions ne doivent pas se chevaucher, et ajoutez une alerte sur le dernier succès.

Champs, alias et dialectes en un coup d’œil

Les cinq champs

Chaque champ accepte les mêmes opérateurs. Seules les bornes changent.

Minute : de 0 à 59

Heure : de 0 à 23

Jour du mois : de 1 à 31

Mois : de 1 à 12, ou de JAN à DEC

Jour de la semaine : de 0 à 7 (0 et 7 valent dimanche), ou de SUN à SAT

<code>*</code> désigne toutes les valeurs, <code>,</code> sépare une liste, <code>-</code> trace une plage inclusive (<code>8-11</code> donne 8, 9, 10 et 11) et <code>/</code> fixe un pas

Avec six champs, les secondes (de 0 à 59) passent en premier

Les alias

Un alias remplace toute l’expression. Le parseur les développe dans la zone de saisie.

<code>@hourly</code> vaut <code>0 * * * *</code>

<code>@daily</code> et <code>@midnight</code> valent <code>0 0 * * *</code>

<code>@weekly</code> vaut <code>0 0 * * 0</code>, soit dimanche à minuit

<code>@monthly</code> vaut <code>0 0 1 * *</code>

<code>@yearly</code> et <code>@annually</code> valent <code>0 0 1 1 *</code>

<code>@reboot</code> dépend du démarrage de la machine et n’a pas de date : le parseur le refuse

GitHub Actions n’accepte aucun de ces alias

Le même planning dans cinq dialectes

Avant de copier une expression, vérifiez ce que la cible comprend.

crontab Unix : cinq champs, au fuseau du système. Certaines implémentations lisent aussi une variable <code>CRON_TZ</code>

Kubernetes CronJob : cinq champs, <code>?</code> équivaut à <code>*</code>, alias acceptés. Le fuseau se règle avec <code>.spec.timeZone</code> (stable depuis Kubernetes 1.27), sinon c’est celui du kube-controller-manager

GitHub Actions : cinq champs en syntaxe POSIX, aucun alias, UTC par défaut, une clé timezone facultative décrite dans la documentation, un intervalle minimal de 5 minutes, et un déclenchement depuis la branche par défaut seulement

AWS EventBridge : six champs, <code>cron(minute heure jour-du-mois mois jour-de-la-semaine année)</code>, avec un <code>?</code> obligatoire dans l’un des deux champs de jour. Les opérateurs <code>L</code>, <code>W</code> et <code>#</code> sont permis. Les règles planifiées comptent en UTC

Quartz et Spring : six champs, les secondes en premier

Le parseur de FastMinify : cinq ou six champs (secondes en premier), alias, noms de mois et de jours, et rien d’autre

Le parseur cron, pas à pas

Lire une expression

Le parseur cron analyse pendant la saisie, après une courte pause. Le bouton Analyser, ou la touche Entrée dans le champ, lance le calcul sans attendre.

Saisissez ou choisissez un préréglage

Six préréglages remplissent le champ : toutes les 5 minutes, toutes les 15 minutes, toutes les heures, tous les jours à minuit, jours ouvrés à 09:00 et le 1er de chaque mois. Un alias comme @daily est remplacé par sa forme à cinq champs.

Lisez la phrase

Pour les plannings simples, une phrase résume l’expression, par exemple « Toutes les 15 minutes » ou « À 09:00 du lundi au vendredi ». Sinon l’outil affiche « Détail du planning » et vous laisse lire les champs.

Vérifiez les cases

Chaque case porte le nom d’un champ et sa valeur. Une note apparaît quand le jour du mois et le jour de la semaine sont tous deux fixés. Elle rappelle que l’un ou l’autre suffit.

Lisez les prochaines exécutions

La liste donne les dates complètes, avec une ligne « Prochaine » qui donne le délai avant la première. Un avertissement apparaît si aucune date n’existe ou si la recherche s’arrête avant d’en trouver assez.

Régler les options

Trois réglages sous le champ de saisie changent ce que l’outil calcule ou affiche.

Cinq ou six champs

Cinq champs est le réglage de départ. Passer à six ajoute 0 en tête de l’expression, donc des secondes à zéro. Repasser à cinq retire ce zéro, et l’outil refuse tant que les secondes valent autre chose que 0.

Exécutions à afficher

Choisissez 5, 10 ou 25. Prenez 25 pour voir le motif d’un pas, d’une fin de mois ou de deux champs de jour combinés.

Fuseau

UTC est le réglage de départ. Local utilise le fuseau de votre navigateur. Un badge au-dessus de la phrase rappelle le choix. Le calcul reste en UTC dans les deux cas : seule l’écriture des dates change.

Copier

Copier la description reprend la phrase, Tout copier reprend la liste, et chaque ligne a son propre bouton Copier.

Comprendre un refus

Quand l’expression est refusée, l’outil dit pourquoi et ne calcule rien.

Expression vide

Un champ vidé après une saisie affiche « Saisissez une expression cron ».

Mauvais nombre de champs

« Expression cron invalide pour le nombre de champs choisi » signale quatre champs, ou six alors que le réglage est sur cinq. Changez le réglage ou corrigez les jetons.

Valeur invalide

Un message comme « Valeur invalide dans Heure (22-2) » nomme le champ et le jeton fautif, et la case du champ est mise en évidence.

Alias non pris en charge

@reboot et tout alias hors liste donnent un message qui rappelle ceux que l’outil accepte.

Les mêmes plannings dans une crontab, Kubernetes, GitHub Actions et Node

Une ligne de crontab

La ligne s’écrit dans crontab -e. La commande occupe le reste de la ligne : un % non protégé y devient un saut de ligne, d’où le \% de l’exemple (selon la page de manuel de crontab). Cron n’exécute pas votre profil de connexion, donnez donc le chemin complet des programmes.

Exemple de base

# m    h     dom mon dow  command
*/15   9-17  *   *   1-5  /usr/local/bin/sync.sh >> /var/log/sync.log 2>&1
0      2     *   *   *    /usr/bin/tar -czf /backup/site-$(date +\%F).tar.gz /var/www

# First Monday only: cron ORs day-of-month and day-of-week, so test the date in the command
0      9     *   *   1    [ "$(date +\%d)" -le 7 ] && /usr/local/bin/monthly-report.sh

Un CronJob Kubernetes

Le fuseau se déclare dans .spec.timeZone, jamais dans schedule. Vérifiez le manifeste avec le validateur Kubernetes avant de l’appliquer.

Exemple de base

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-report
spec:
  schedule: "0 9 * * 1-5"        # five fields, no CRON_TZ or TZ prefix
  timeZone: "Europe/Paris"       # without it, the time zone of kube-controller-manager applies
  concurrencyPolicy: Forbid      # skip a run while the previous one is still running
  startingDeadlineSeconds: 300   # do not start a run more than 5 minutes late
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: report
              image: registry.example.com/report:1.4.2
              command: ["/app/run-report"]

Un workflow GitHub Actions

Le workflow ne se déclenche que s’il existe sur la branche par défaut. Le validateur GitHub Actions contrôle le fichier. Le parseur cron vérifie les dates.

Exemple de base

on:
  schedule:
    # Minute 17 avoids the busiest moment, the start of the hour. UTC by default.
    - cron: "17 7 * * 1-5"
    # Optional IANA time zone, as described in the GitHub documentation
    - cron: "30 5 * * 1-5"
      timezone: "America/New_York"

La bibliothèque cron-parser avec Node

Pour calculer les prochaines exécutions dans un fuseau, comme le fait un vrai cron, passez l’option tz. L’exemple utilise la version 5 de la bibliothèque. Il montre l’écart avec le parseur de FastMinify, qui calcule en UTC : la même ligne donne 07:00 UTC avant le 25 octobre 2026 et 08:00 UTC après, pour une heure de Paris.

Exemple de base

import { CronExpressionParser } from 'cron-parser'

// Same line, two zones: 09:00 UTC is not 09:00 in Paris
const options = { currentDate: '2026-10-23T12:00:00Z', tz: 'Europe/Paris' }
const paris = CronExpressionParser.parse('0 9 * * *', options)
for (let i = 0; i < 3; i++) console.log(paris.next().toISOString())
// 2026-10-24T07:00:00.000Z  (09:00 CEST, UTC+2)
// 2026-10-25T08:00:00.000Z  (09:00 CET, UTC+1: the clocks went back that night)
// 2026-10-26T08:00:00.000Z

const utc = CronExpressionParser.parse('0 9 * * *', { ...options, tz: 'UTC' })
console.log(utc.next().toISOString()) // 2026-10-24T09:00:00.000Z, what the parser tool shows

Conclusion

Une expression cron tient en cinq champs, et presque toute l’erreur vient de ce qu’on n’y voit pas. Un pas repart de zéro, deux champs de jour se combinent en OU, une date n’existe pas, un fuseau ou un changement d’heure déplace tout. Le parseur cron met des dates en face de la ligne, ce qui permet de repérer ces cas avant le déploiement. Il calcule en UTC, ne lance aucune tâche et ne connaît que les cinq ou six champs et les alias courants. La cible compte autant que l’expression : crontab, Kubernetes, GitHub Actions, EventBridge et Quartz ne lisent pas la même syntaxe. Gardez des tâches qu’on peut relancer sans dégât et surveillez leur dernier succès. Le hub des utilitaires développeur réunit les outils voisins.

Analyser une expression cron dans votre navigateur

Parseur cron Timestamp Unix Validateur Kubernetes Hub des utilitaires

Collez l’expression dans le parseur et lisez les dates en plus de la phrase de résumé

Demandez 25 exécutions pour voir le motif d’un pas, d’une fin de mois ou de deux champs de jour combinés

Décidez du fuseau avant d’écrire l’heure, et écrivez des tâches qu’on peut relancer sans dégât

Évitez la nuit du changement d’heure et le début de l’heure pour une tâche qui compte

Notez le dialecte de la cible : alias, secondes, année et fuseau ne se traitent pas partout de la même façon

Partager cet article

Partager cet article:

Articles connexes

Calculateur de sous-réseau CIDR : calculer, agréger des plages et tester une IP

Calculez réseau, masque, plage d’hôtes et broadcast d’un CIDR, agrégez des plages en blocs minimaux et testez une IP, directement dans votre navigateur.

11.10.202618 min de lecture

Inspecter une requête HTTP : curl, message brut et HAR

Formatez un Copy as cURL, analysez une requête ou une réponse HTTP brute et lisez un export HAR dans votre navigateur : rien n’est envoyé ni rejoué.

07.10.202618 min de lecture

JWT encode/decode : fabriquer et inspecter un token en ligne

Décodez l'en-tête et le payload d'un JWT ou signez un token de test dans votre navigateur : HS256, RS256, ES256, sans envoyer de secret à un tiers.

04.10.202618 min de lecture