n8n Schedule Trigger : maîtriser les expressions cron et les fuseaux horaires

Un digest d'emails envoyé à 3h du matin plutôt qu'à 8h, un rapport SEO hebdomadaire qui part le lundi au lieu du vendredi, une relance de dossier incomplet qui ne part jamais parce que l'instance était en cours de redémarrage : la plupart des incidents liés au Schedule Trigger de n8n ne viennent pas d'une erreur de configuration visible, mais d'une hypothèse implicite sur le fuseau horaire ou la fiabilité du déclenchement. Ce node est pourtant au cœur de plusieurs workflows FlowKit — le digest quotidien du Pack Inbox IA, les relances du Pack Conformité & Audit, la synchronisation nocturne du Pack Assistant RAG — ce qui justifie de le comprendre en détail avant de le mettre en production.

Les deux modes du Schedule Trigger

Le node propose deux façons de définir une cadence, réunies sous une même « Trigger Rule » (et vous pouvez en ajouter plusieurs dans le même node, voir plus bas) :

• Interval — des champs guidés : Secondes, Minutes, Heures, Jours, Semaines ou Mois, avec des sous-champs comme « Trigger at Hour » et « Trigger at Minute ». C'est le mode recommandé pour 90 % des cas : un digest tous les jours à 8h, une synchronisation toutes les 15 minutes, un rapport chaque lundi à 7h.
• Cron Expression — une chaîne au format cron classique à cinq champs (minute, heure, jour du mois, mois, jour de la semaine), avec un sixième champ optionnel ajouté au début pour les secondes. C'est le mode à utiliser dès que le besoin dépasse ce que l'interface guidée peut exprimer : 0 8 1-7 * 1 pour « le premier lundi de chaque mois », ou */10 8-18 * * 1-5 pour « toutes les 10 minutes, de 8h à 18h, du lundi au vendredi ».

Pour construire ou relire une expression cron sans erreur, un outil comme crontab.guru (non affilié à n8n) reste le réflexe le plus rapide avant de coller l'expression dans le champ.

Plusieurs règles dans un seul node

Un piège classique consiste à dupliquer tout un workflow pour gérer deux cadences différentes — par exemple un digest toutes les heures en semaine et un seul le samedi matin. Le Schedule Trigger accepte d'ajouter plusieurs Trigger Rules au même node : chacune peut être en mode Interval ou Cron Expression indépendamment, et le workflow se déclenche dès que l'une d'entre elles s'active. Cela garde un seul workflow à maintenir plutôt que deux copies qui finissent par diverger.

Fuseaux horaires : le piège le plus courant

C'est la source d'erreur numéro un avec ce node, précisément parce qu'elle ne produit pas d'erreur visible — le workflow se déclenche, juste au mauvais moment. La résolution du fuseau horaire suit un ordre précis :

1. Le fuseau du workflow, réglable dans les paramètres du workflow (menu à trois points → Settings → Timezone). Il prévaut sur tout le reste dès qu'il est défini.
2. Le fuseau de l'instance, fixé par la variable d'environnement GENERIC_TIMEZONE en self-hosted. Sans cette variable, n8n retombe sur America/New_York — un fuseau qui décale de 5 à 6 heures un digest censé partir à 8h pour une équipe basée en France.
3. Sur n8n Cloud, le fuseau est détecté automatiquement à la création du compte ; à défaut, il retombe sur GMT.

La bonne pratique consiste à ne jamais s'appuyer sur le comportement par défaut : définissez GENERIC_TIMEZONE=Europe/Paris (ou le fuseau pertinent) au niveau de l'instance self-hosted, et réglez explicitement le fuseau dans les paramètres de chaque workflow critique. Utiliser un nom de fuseau IANA complet (Europe/Paris, pas CET ni un simple décalage horaire) évite toute ambiguïté au moment du passage à l'heure d'été ou d'hiver, que le système gère automatiquement avec le bon nom de fuseau.

Ce que contiennent réellement les workflows FlowKit

Trois workflows vendus sur ce site démarrent par un Schedule Trigger. Voici leurs réglages, relevés dans les fichiers JSON livrés (pas une reconstitution) :

Workflow	Nom du node	Mode	Expression	Ce que ça donne
Digest quotidien des emails (Pack Inbox IA)	« Tous les jours à 8h »	Cron Expression	0 8 * * *	tous les jours, 8h00
Relances des dossiers incomplets (Pack Conformité & Audit)	« Chaque matin à 9h »	Cron Expression	0 9 * * 1-5	du lundi au vendredi, 9h00
Synchronisation Notion → base vectorielle (Pack Assistant RAG)	« Toutes les nuits à 2h »	Cron Expression	0 2 * * *	tous les jours, 2h00

Point important, et c'est tout le sujet de la section précédente : aucun de ces trois fichiers ne fixe de fuseau dans ses paramètres de workflow (le bloc settings ne contient que executionOrder: v1). Ils se déclenchent donc à 8h, 9h ou 2h dans le fuseau de votre instance. C'est un choix : un fuseau figé dans le fichier serait faux pour une partie des acheteurs. Conséquence pratique après import :

1. en self-hosted, vérifiez que GENERIC_TIMEZONE vaut bien votre fuseau (Europe/Paris pour la France) ;
2. ou réglez le fuseau dans les paramètres de chacun de ces workflows (Settings → Timezone) ;
3. puis contrôlez l'heure de la prochaine exécution dans l'onglet Executions avant de laisser tourner.

Le choix 1-5 pour les relances n'est pas anodin : relancer un client un samedi matin coûte plus en image que cela ne rapporte en dossiers complétés. Pour un exemple hors packs, le guide sur l'automatisation Search Console utilise 0 7 * * 1 (chaque lundi à 7h).

Que se passe-t-il si l'instance est hors ligne au moment prévu ?

Un déclenchement planifié manqué reste manqué : n8n ne rattrape pas automatiquement une exécution dont l'heure est passée pendant que l'instance était indisponible (redémarrage, panne, mise à jour). Ce n'est pas une lacune propre à n8n mais une caractéristique générale des systèmes de type cron sur une seule machine — c'est justement le problème qu'analyse une étude de Google publiée dans Communications of the ACM (Davidovič & Guliani, 2015) : sur un cron classique, le domaine de panne se limite à une seule machine, et si elle est indisponible, ni le scheduler ni les jobs qu'il devait lancer ne s'exécutent — ce qui a poussé Google à concevoir un service de cron distribué pour ses propres besoins internes.

Pour une instance n8n self-hosted, la conclusion pratique est double :

• Une supervision de disponibilité de l'instance elle-même (pas seulement des exécutions) est indispensable dès qu'un workflow planifié porte un enjeu métier réel — voir nos réflexes de fiabilité dans le guide self-hosted vs cloud.
• Un Error Workflow capture les échecs d'exécution, mais pas les déclenchements qui n'ont jamais eu lieu faute d'instance disponible — les deux problèmes se traitent séparément.
• Si le volume de déclenchements planifiés devient important sur une instance qui tourne déjà en mode queue avec Redis, gardez en tête que c'est l'instance principale, pas les workers, qui porte la responsabilité de déclencher les crons à l'heure.

Bonnes pratiques à retenir

• Toujours fixer le fuseau explicitement — au niveau de l'instance (GENERIC_TIMEZONE) et de chaque workflow critique, avec un nom IANA complet.
• Préférer Interval quand c'est suffisant : plus lisible pour une équipe qui reprend le workflow plus tard qu'une expression cron à décoder.
• Grouper les cadences avec plusieurs Trigger Rules plutôt que dupliquer des workflows entiers.
• Espacer les déclenchements fréquents pour rester sous les quotas des API IA appelées en aval — voir notre article sur les erreurs 429 et le cadencement des appels IA.
• Tester le workflow manuellement (bouton « Execute workflow ») avant d'activer le Schedule Trigger en production, pour valider la logique indépendamment de l'heure de déclenchement.

Bien réglé, le Schedule Trigger devient invisible — le digest arrive à l'heure, la relance part le bon jour, le rapport tombe avant la réunion. C'est un détail de configuration qui prend cinq minutes à vérifier, et qui évite des semaines de confusion sur « pourquoi ce workflow ne s'est pas déclenché quand il fallait ». Les workflows planifiés des packs Inbox IA (79 €), Assistant RAG (119 €) et Conformité & Audit (149 €) arrivent avec leur Schedule Trigger déjà configuré — il ne reste qu'à ajuster le fuseau à votre équipe.