n8n Schedule Trigger спрацьовує не вчасно? Часовий пояс і літній час
Schedule Trigger у n8n спрацьовує не вчасно? Дізнайтеся, який часовий пояс бере n8n, як задати GENERIC_TIMEZONE або налаштування Cloud і врахувати літній час.
Перевірено за наведеними джерелами .
Мета, передумови та як n8n обирає часовий пояс
Schedule Trigger у n8n спрацьовує не в той час і запуски відбуваються на кілька годин раніше чи пізніше, ніж ви задали? За документацією n8n, одна з поширених причин — налаштування часового поясу, яке використовує n8n. Після цього туторіалу ваш запланований workflow запускатиметься в той місцевий час, який ви мали на увазі, а ви знатимете, що перевіряти під час переходу на літній чи зимовий час.
Вам потрібен запланований workflow, який ви можете редагувати, і доступ до його налаштувань. Щоб змінити типове значення для всього інстансу, потрібен також доступ до дашборду n8n Cloud або до змінних середовища self-hosted інстансу.
За документацією n8n, Schedule Trigger бере часовий пояс із налаштувань, наведених у таблиці нижче. Типові значення можуть не збігатися з вашим місцезнаходженням, тож workflow без явно заданого поясу може запускатися на кілька годин не тоді, коли ви очікуєте.
| Налаштування | Де змінити | Типове значення |
|---|---|---|
| Workflow Timezone | Налаштування workflow | Не задано: використовується часовий пояс інстансу |
| Часовий пояс інстансу (Cloud) | Dashboard, Manage, Timezone | Визначається під час реєстрації, інакше GMT |
| Часовий пояс інстансу (self-hosted) | Змінна GENERIC_TIMEZONE | America/New_York |
Sources: Schedule Trigger | Nodes | n8n Docs, Common issues | Nodes | n8n Docs
Кроки, щоб виправити часовий пояс у n8n
Щоб Schedule Trigger у n8n спрацьовував вчасно, за документацією можна змінити часовий пояс для окремого workflow або для всього інстансу. Виконуйте кроки по черзі. Спершу варто задати часовий пояс workflow, бо він має пріоритет над типовим значенням інстансу (див. таблицю вище).
Як виправити часовий пояс розкладу
- Відкрийте налаштування workflow: Відкрийте workflow на полотні, натисніть значок із трьома крапками у верхньому правому куті, потім Settings.
- Задайте Timezone: Оберіть іменований пояс, наприклад Europe/London, і натисніть Save.
- Задайте типове значення інстансу: У Cloud натисніть Manage на дашборді й змініть Timezone; у self-hosted задайте GENERIC_TIMEZONE.
- Опублікуйте повторно: Зніміть workflow з публікації та опублікуйте знову, щоб розклад використовував нові налаштування.
- Перевірте: Переконайтеся, що наступний запуск відбувся в запланований місцевий час.
У n8n Cloud, за документацією, налаштування Timezone на дашборді впливає і на Schedule Trigger, і на вузол Date & Time. У документації Cloud не вказано, яких тарифних планів це стосується. Для self-hosted n8n документація наводить приклад експорту змінної середовища GENERIC_TIMEZONE зі значенням Europe/Berlin. Чи потрібен після цього перезапуск, не сказано. Наша редакційна порада — про всяк випадок заплануйте перезапуск.
За документацією, зміна інтервалу тригера набирає чинності лише після того, як ви знімете workflow з публікації та опублікуєте нову версію. Новий розклад тоді відраховується від моменту публікації. Чи потрібна повторна публікація після зміни часового поясу, документація не каже. Опублікувати повторно в будь-якому разі — це наша редакційна порада, а не задокументована поведінка. Назви елементів інтерфейсу також можуть відрізнятися між версіями.
Sources: Schedule Trigger | Nodes | n8n Docs, Common issues | Nodes | n8n Docs, Set the timezone | Deploy | n8n Docs, Set your timezone | Deploy | n8n Docs
Літній час у n8n: оберіть правильний тип поясу
Обирайте пояс залежно від того, що має лишатися незмінним: місцевий час на годиннику чи час UTC. Наша редакційна порада: якщо важливий місцевий час, природний вибір — іменований регіональний пояс, як-от Europe/London, а якщо запуск має бути прив’язаний до UTC — фіксований варіант GMT без переходу на літній час.
Документація n8n цього не описує; це описано в одній гілці форуму спільноти 2024 року щодо n8n 1.38.2 у Docker, тож сприймайте це як окремий випадок, а не задокументовану поведінку. У тій гілці користувач задав для workflow лондонський час, а очікував GMT. Під час британського літнього часу тригер спрацьовував на годину інакше, ніж за GMT. Учасник, який відповів, пояснив, що тригер коректно дотримувався лондонського часу, і порадив варіант GMT без літнього часу, якщо запуск має збігатися із сервером у UTC.
Документація n8n не пояснює, що відбувається із запусками, запланованими на годину, яку пропускають або повторюють під час переведення годинників. Наша редакційна порада: не плануйте важливі завдання на цей проміжок.
Sources: Schedule Trigger and Confusion Over Time Zone Settings in n8n Workflow - Questions - n8n Community
Очікуваний результат і усунення проблем
Після повторної публікації, коли настане наступний запланований час, перевірте, що запуск відбувся в місцевий час, заданий у Timezone workflow. Якщо Schedule Trigger у n8n досі спрацьовує не вчасно, пройдіться цими перевірками.
Наша редакційна рекомендація: команди можуть домовитися про спільне правило — кожен запланований workflow має явно заданий іменований часовий пояс, а у стандартах роботи з workflow зафіксовано часовий пояс інстансу, чи то GENERIC_TIMEZONE, чи налаштування на дашборді Cloud.
Sources: Schedule Trigger | Nodes | n8n Docs, Common issues | Nodes | n8n Docs, Set the timezone | Deploy | n8n Docs, Set your timezone | Deploy | n8n Docs
