L'expression cron est presque toujours correcte, le fuseau horaire non. Trois cas réels du forum n8n montrent pourquoi les Schedule Triggers se déclenchent au mauvais moment.
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.
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 :
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.
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.
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.
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é.
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.
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.
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.
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.
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.
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.
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é.
NordFlux construit des employés numériques pour les organisations : des automatisations et des agents KI qui prennent en charge le travail répétitif. Vous gardez le contrôle.
Aperçu de tous les types de déclencheurs n8n : Schedule, Webhook, Polling, Manuel et Chat, avec une recommandation d'utilisation pour chaque scénario.
Vous reconnaissez les stuck executions dans n8n à des indicateurs de statut qui restent bloqués. Voici comment bien configurer EXECUTIONS_TIMEOUT et trouver la cause.
Par défaut, n8n s'exécute en America/New_York au lieu de Europe/Berlin. Voici comment configurer correctement GENERIC_TIMEZONE et le fuseau horaire du workflow.
Instance, workflow et worker peuvent chacun avoir leur propre fuseau horaire, et c'est précisément cette interaction qui provoque les erreurs Cron classiques. NordFlux prend en charge l'exploitation encadrée de votre instance n8n et veille à ce que les workflows planifiés se déclenchent bien à l'heure prévue. Lors du premier échange, nous examinons concrètement votre configuration de déclencheurs.
