Configurer correctement le Cron et le Schedule Trigger dans n8n : le fuseau horaire est presque toujours en cause

L'expression cron dans le Schedule Trigger est presque toujours correcte. Ce qui, en pratique, n'est le plus souvent pas correct, c'est le fuseau horaire dans lequel n8n évalue cette expression. Exactement ce schéma se retrouve dans trois vrais fils de discussion du forum n8n, que nous examinons en détail dans cet article : une équipe en mode Queue, un utilisateur au Brésil et un utilisateur à Londres qui s'étonnait d'une différence d'une heure alors que le réglage de son workflow était sur GMT. Dans les trois cas, l'expression cron elle-même était correcte, la cause se trouvait un niveau plus bas.

Selon la documentation officielle du Schedule Trigger le nœud utilise une hiérarchie de fuseaux horaires à plusieurs niveaux, et c'est exactement là que naissent la plupart des surprises. Si vous comprenez comment n8n résout ces niveaux, vous pouvez éviter presque tous les bugs de fuseau horaire avant même qu'ils ne passent en production. État : juillet 2026.

Comment le Schedule Trigger interprète les expressions cron

En mode personnalisé, le Schedule Trigger accepte, selon la documentation, une expression cron classique à six champs, le sixième champ, optionnel, représentant les secondes, suivi de la minute, de l'heure, du jour du mois, du mois et du jour de la semaine. La documentation liste à ce sujet un tableau de référence avec des modèles courants :

• Toutes les X secondes : `*/10 * * * * *`
• Toutes les X minutes : `*/5 * * * *`
• Toutes les heures : `0 * * * *`
• Quotidiennement : `0 6 * * *`
• Hebdomadairement : `0 12 * * 1`
• Mensuellement : `0 0 1 * *`

Pour les tests, n8n recommande lui-même de vérifier au préalable une expression sur crontab.guru, mais sans la colonne optionnelle des secondes, car cet outil ne connaît que cinq champs. Cette seule étape aide à exclure les erreurs de syntaxe avant même d'aborder les pièges liés au fuseau horaire. L'expression elle-même est anodine dans presque tous les problèmes discutés publiquement, le problème ne commence qu'après, avec la question de savoir dans quel fuseau horaire n8n évalue réellement cette expression.

La hiérarchie des fuseaux horaires : instance, workflow et worker

n8n établit un ordre de priorité clair pour le fuseau horaire. Si un fuseau horaire est défini dans le workflow lui-même, celui-ci s'applique. S'il est absent, n8n se rabat sur le fuseau horaire de l'instance. Pour les instances auto-hébergées, la valeur par défaut n'est pas UTC ni le fuseau horaire de votre serveur, mais selon la documentation `America/New_York`. Sur n8n Cloud, le système tente de détecter automatiquement le fuseau horaire du titulaire du compte, mais se rabat sur GMT en cas d'échec de la détection.

La page sur les problèmes fréquents du Schedule Trigger décrit exactement ce mécanisme comme la source d'erreur la plus fréquente et nomme deux leviers : au niveau du workflow, le fuseau horaire peut être ajusté via les trois points en haut à droite du canvas, puis Settings et le paramètre Timezone. Globalement, pour toute l'instance, sur les installations auto-hébergées, vous définissez à la place la variable d'environnement `GENERIC_TIMEZONE`. Important : cette variable agit sur l'instance, pas automatiquement sur chaque processus individuel appartenant à cette instance, comme le montre le premier cas ci-dessous.

Trois vrais cas issus du forum n8n

Cas 1 : mode Queue, correctement configuré, mais quand même faux

Dans le fil "Schedule Trigger executing at wrong time" un utilisateur décrit un déclencheur hebdomadaire censé s'exécuter le dimanche à 3 heures PST, mais qui se déclenchait en réalité à 19 heures. Aussi bien le réglage du workflow que le fuseau horaire de l'installation étaient correctement réglés sur PST, un ancien nœud Cron fonctionnait même en parallèle sans erreur. L'utilisateur a trouvé lui-même la solution : "We use n8n in queue mode - and it turns out, I forgot to set the timezone parameters on the workers!!!" L'instance principale avait le bon fuseau horaire, mais pas les pods worker séparés dans Kubernetes. Après avoir défini la variable d'environnement TZ sur les déploiements worker, le workflow de test s'est exécuté "on the dot", comme le confirme l'utilisateur. Quiconque exploite n8n en mode Queue doit donc définir le fuseau horaire sur chaque composant individuel, pas seulement sur l'instance principale.

Cas 2 : le Brésil et la valeur par défaut silencieuse

Dans le fil "Schedule Trigger - what's the time zone?" un utilisateur du Brésil (UTC-3) signale une différence d'exactement deux heures : un déclencheur programmé pour 11 heures s'est exécuté à 13 heures à la place. La cause était simplement la valeur par défaut non écrasée `America/New_York`, que n8n applique aux instances auto-hébergées lorsque personne ne configure explicitement autre chose. Deux solutions ont été mentionnées, soit modifier le fuseau horaire directement dans le workflow via Settings, soit le définir globalement via `GENERIC_TIMEZONE` dans le fichier Docker Compose ou dans l'image Docker. Quiconque met en place une nouvelle installation n8n devrait donc penser à cette variable dès le début, plutôt que de l'ajouter seulement après le premier déclenchement erroné.

Cas 3 : Londres, l'heure d'été et le malentendu autour de GMT

Dans le fil "Schedule Trigger and Confusion Over Time Zone Settings" l'utilisateur kpakfar s'étonnait d'une différence d'une heure entre `DateTime.now()`, qui affichait correctement l'heure de Londres, heure d'été comprise, et le Schedule Trigger, qui semblait fonctionner selon le réglage nommé GMT. Le membre de la communauté ihortom a clarifié que le déclencheur fonctionnait correctement selon l'heure de Londres, et non selon la désignation littérale "GMT 00:00". Précision à ce sujet : quiconque veut vraiment un fuseau horaire fixe sans passage à l'heure d'été doit sélectionner explicitement "(GMT+00:00) GMT (no daylight saving)". L'option de fuseau horaire normale, liée à une ville, prend automatiquement en compte l'heure d'été, même si son libellé ne le révèle pas au premier coup d'œil. Quiconque a besoin d'heures UTC fixes indépendamment de l'heure d'été, par exemple pour des systèmes qui parlent eux-mêmes UTC, devrait choisir spécifiquement la variante sans heure d'été plutôt qu'un fuseau horaire basé sur une ville.

Comment configurer le fuseau horaire de manière fiable

• Vérifier l'expression cron séparément : Testez d'abord la syntaxe pure sur crontab.guru, sans le champ optionnel des secondes, avant de vous occuper du fuseau horaire.
• Définir explicitement le fuseau horaire du workflow : Ne vous fiez pas au réglage par défaut de l'instance, mais indiquez le fuseau horaire dans les paramètres du workflow, en particulier avec plusieurs workflows destinés à des publics ou des pays différents.
• Définir `GENERIC_TIMEZONE` en auto-hébergement : Sans cette variable, votre instance reste sur `America/New_York`, indépendamment de l'endroit où votre serveur fonctionne réellement.
• Mode Queue : ne pas oublier les workers : Définissez le fuseau horaire sur chaque déploiement worker individuellement, une instance principale correctement configurée ne suffit pas à elle seule.
• Décider consciemment de l'heure d'été : Choisissez un fuseau horaire basé sur une ville si l'heure d'été doit s'appliquer automatiquement, ou une variante fixe sans heure d'été si vous avez besoin d'une heure UTC exacte indépendamment de la saison.

Chez NordFlux, nous configurons les workflows n8n de façon à ce que les déclencheurs cron s'exécutent dès le départ dans le bon fuseau horaire, que ce soit sur une instance unique ou en mode Queue avec plusieurs workers. Vos automatisations sensibles au temps restent ainsi fiables, et vous gardez le contrôle sur le moment où vos collaborateurs numériques se mettent réellement en marche. Vous trouverez plus d'informations sur notre approche sous l'automatisation n8n par NordFlux.

Questions fréquentes

Pourquoi mon déclencheur cron s'exécute-t-il au mauvais moment alors que l'expression est correcte ?

Dans la grande majorité des cas, ce n'est pas l'expression cron elle-même qui est en cause, mais le fuseau horaire dans lequel n8n l'évalue. Vérifiez d'abord les paramètres du workflow, puis le fuseau horaire de l'instance, et en mode Queue, en plus, le fuseau horaire sur chaque worker.

Quel est le fuseau horaire par défaut de n8n si je ne règle rien ?

Pour les instances auto-hébergées, la valeur par défaut selon la documentation est `America/New_York`. Sur n8n Cloud, le système tente de détecter automatiquement le fuseau horaire, et se rabat sur GMT en cas d'échec de la détection. Les deux valeurs par défaut correspondent rarement par hasard à votre fuseau horaire réel.

Comment régler le fuseau horaire pour un seul workflow ?

Ouvrez le workflow dans le canvas, cliquez sur les trois points en haut à droite, choisissez Settings et ajustez le paramètre Timezone. Ce réglage remplace le fuseau horaire de l'instance uniquement pour ce workflow.

Dois-je tenir compte d'autre chose en mode Queue ?

Oui. Le réglage du fuseau horaire de l'instance principale ne suffit pas en mode Queue, car les déclencheurs s'exécutent sur des processus worker séparés. Définissez la variable d'environnement TZ appropriée sur chaque déploiement worker, sinon l'instance principale peut être correctement configurée et le déclencheur peut quand même se déclencher au mauvais moment.

Comment éviter les surprises liées à l'heure d'été ?

Un fuseau horaire basé sur une ville comme Londres ou Berlin s'adapte automatiquement à l'heure d'été et à l'heure normale. Si vous voulez au contraire une heure fixe indépendamment de la saison, choisissez explicitement une option de fuseau horaire sans heure d'été, plutôt que de vous fier uniquement au libellé.