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.

Cas d'usage concrets dans les packs FlowKit

• Digest quotidien (Pack Inbox IA) : un Schedule Trigger en mode Interval déclenche chaque matin la synthèse des emails de la veille vers Slack ou Telegram. Un décalage de fuseau ici veut dire un digest reçu en pleine nuit ou en plein après-midi plutôt qu'au réveil de l'équipe.
• Relances de dossiers incomplets (Pack Conformité & Audit, détaillé dans notre article sur les relances automatisées de dossiers) : ici la cadence — souvent quotidienne ou hebdomadaire — a un impact direct sur des échéances réglementaires, ce qui rend la fiabilité du déclenchement particulièrement sensible.
• Rapport SEO hebdomadaire (voir notre guide sur l'automatisation Search Console) : un Cron Expression du type 0 7 * * 1 envoie le rapport chaque lundi à 7h, avant le point d'équipe hebdomadaire.
• Synchronisation nocturne Notion → Supabase (Pack Assistant RAG) : un déclenchement planifié en heures creuses évite de réindexer la base vectorielle pendant que l'équipe l'interroge activement.

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 — Google Scholar) : 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.