Automatisation

n8n Schedule Trigger : régler le fuseau horaire

Workflow n8n lancé à la mauvaise heure ? Fuseau du workflow ou de l'instance, GENERIC_TIMEZONE, exécutions manquées : les réglages à vérifier.

· 7 min de lecture · InfiniteLab

Un rapport censé partir à 9 h arrive en milieu d'après-midi. Une relance commerciale se déclenche en pleine nuit. Le workflow n8n est bien actif, l'expression cron est correcte, et pourtant l'heure est fausse. Dans la grande majorité de ces cas, le problème n'est pas la planification elle-même : c'est le fuseau horaire que n8n applique, et que personne n'a choisi.

Cet article explique comment n8n détermine le fuseau d'un Schedule Trigger, quels réglages contrôler dans quel ordre, et ce qui se passe quand l'instance est arrêtée à l'heure prévue. Les faits sur n8n viennent de sa documentation officielle, citée en fin d'article ; les recommandations sont notre analyse, à adapter à votre contexte.

Comment n8n choisit le fuseau horaire

D'après la documentation du nœud Schedule Trigger, le nœud « dépend du réglage de fuseau horaire » et n8n utilise l'un de ces deux fuseaux :

  1. Le fuseau du workflow, s'il est défini dans les paramètres du workflow ;
  2. Le fuseau de l'instance, si celui du workflow n'est pas défini.

Le point qui surprend : la documentation indique que la valeur par défaut est America/New_York pour une instance auto-hébergée, tandis que n8n Cloud retombe sur GMT. La page des paramètres de workflow le confirme : si ni le workflow ni l'instance ne sont configurés, n8n utilise le fuseau de New York.

Concrètement, un workflow réglé sur « tous les jours à 9 h » dans une instance auto-hébergée qui n'a jamais été configurée se déclenche à 9 h heure de New York, soit plusieurs heures de décalage avec Paris. Rien n'est cassé : n8n fait exactement ce qu'on lui a demandé, dans un fuseau qu'on ne lui a pas précisé.

Les deux endroits où le régler

Niveau Où Portée
Instance Variable d'environnement GENERIC_TIMEZONE (auto-hébergé) ou paramètres de l'instance (Cloud) Valeur par défaut de tous les workflows
Workflow Paramètres du workflow, champ Timezone Ce workflow uniquement, prioritaire sur l'instance

La documentation des variables d'environnement décrit GENERIC_TIMEZONE comme le fuseau de l'instance, « important pour les nœuds de planification (comme Cron) ». Sa valeur par défaut est America/New_York. Le format attendu est un identifiant de fuseau comme Europe/Paris, pas un décalage (« UTC+1 »).

Notre recommandation : définissez le fuseau de l'instance une fois pour toutes, et ne le surchargez dans un workflow que lorsqu'un traitement doit réellement suivre l'heure d'un autre pays (par exemple, un envoi à 8 h heure de Montréal). Un fuseau décidé par défaut au niveau de l'instance évite qu'un nouveau workflow hérite d'un réglage inattendu.

Avec Docker Compose, cela revient à ajouter la variable à l'environnement du conteneur n8n, puis à recréer le conteneur pour qu'elle soit prise en compte :

services:
  n8n:
    environment:
      - GENERIC_TIMEZONE=Europe/Paris

La documentation consultée ne décrit pas le comportement d'autres variables d'horloge du conteneur : ne supposez pas qu'elles s'alignent. Après tout changement, vérifiez le résultat (voir plus bas).

Les pièges de l'expression cron

Le Schedule Trigger propose les intervalles Secondes, Minutes, Heures, Jours, Semaines, Mois et un mode personnalisé en cron. Quelques points issus de la documentation :

  • Les variables dans une expression cron sont évaluées à la publication. Modifier la variable ensuite ne change pas la planification tant que vous ne dépubliez pas, puis republiez le workflow.
  • Enregistrer ne suffit pas. La documentation demande d'enregistrer et de publier le workflow pour que le déclencheur soit actif.
  • Un cron à six champs ajoute les secondes. Le sixième champ est facultatif. Un exemple de la documentation : 0 9 * * 1-5 pour les jours ouvrés à 9 h.
  • Le rythme des intervalles courts a changé. Depuis la version 2.45.0, les intervalles en secondes et en minutes s'exécutent à intervalles réguliers à partir de la publication, et non plus sur les repères de l'horloge. Les expressions cron conservent leur calage. Si vous comptiez sur un déclenchement « à la minute pile », vérifiez votre version.

Le changement d'heure d'été n'est pas traité dans la documentation du nœud que nous avons consultée. Si un traitement doit absolument partir à une heure locale précise les jours de changement, testez-le plutôt que de le supposer.

Que se passe-t-il si l'instance est arrêtée à l'heure prévue

C'est la deuxième source de surprises : une mise à jour, un redémarrage ou une panne qui tombe pile à l'heure du déclenchement. D'après la documentation, l'onglet des paramètres du workflow propose le réglage des exécutions manquées, avec Don't Run Missed Executions par défaut. Deux autres options exécutent un rattrapage unique, soit une fois au total, soit une fois par règle de déclenchement. Ces options ne prennent effet que lorsque le planificateur durable est actif, ce qui est le cas par défaut depuis la version 2.45.0.

En pratique, par défaut, une exécution manquée est perdue. Pour un rapport quotidien, c'est parfois acceptable. Pour une facturation, une synchronisation ou une relance, choisissez consciemment :

  • Rattrapage unique si une exécution tardive vaut mieux qu'aucune, et si le traitement peut tourner à n'importe quelle heure sans conséquence ;
  • Pas de rattrapage si une exécution tardive est pire qu'aucune (par exemple, un message « bonjour » envoyé le soir).

Dans les deux cas, prévoyez une alerte : un workflow planifié qui ne s'est pas exécuté ne produit pas d'erreur, donc rien ne vous prévient. Notre article sur la gestion des erreurs avec Error Trigger décrit l'alerte sur échec ; pour détecter l'absence d'exécution, il faut en plus un contrôle de résultat (voir ci-dessous). Si vous rattrapez des traitements, protégez-les aussi contre un double passage : voir notre article sur les doublons avec Remove Duplicates.

Une procédure de vérification en cinq minutes

Avant de faire confiance à une planification, vérifiez-la plutôt que de la déduire :

  1. Notez le fuseau attendu (par exemple Europe/Paris) pour ce workflow.
  2. Contrôlez le fuseau du workflow, dans ses paramètres : s'il est vide, c'est l'instance qui décide.
  3. Contrôlez le fuseau de l'instance, via la variable GENERIC_TIMEZONE de l'environnement qui exécute n8n.
  4. Programmez un test à court terme : un déclenchement dans quelques minutes, avec un nœud qui écrit l'heure locale attendue et l'heure réellement observée dans le message ou le journal.
  5. Comparez avec l'heure d'exécution affichée dans l'historique des exécutions.

Si vous exploitez n8n en mode queue avec plusieurs workers, appliquez la même configuration à tous les processus et testez après chaque modification de l'infrastructure : plusieurs processus signifient plusieurs endroits où une variable peut manquer.

Les erreurs fréquentes

  • Penser que « l'heure du serveur » décide. Pour le Schedule Trigger, c'est le fuseau du workflow, sinon celui de l'instance, qui compte.
  • Corriger le fuseau d'un seul workflow alors que tous les workflows planifiés héritent du même défaut.
  • Utiliser un décalage au lieu d'un identifiant de fuseau : le décalage ne dit rien sur le changement d'heure.
  • Modifier une variable dans l'expression cron sans republier le workflow.
  • Ne rien prévoir pour une exécution manquée sur un traitement qui compte.
  • Ne jamais contrôler le résultat attendu : une alerte d'erreur ne détecte pas un workflow qui n'a pas tourné.

Besoin de planifications fiables ?

Vos workflows n8n partent à des heures inattendues, ou vous ne savez pas ce qui se passe quand l'instance redémarre à l'heure d'un traitement ? Décrivez-nous votre situation : nous vérifions le fuseau, le réglage des exécutions manquées et l'alerte qui manque, puis nous mettons en place un contrôle de résultat adapté. Notre approche part toujours d'un processus précis, et nos offres détaillent les formats d'accompagnement.

Sources