Выражение cron почти всегда верное, часовой пояс нет. Три реальных случая с форума n8n показывают, почему Schedule Trigger срабатывает не в то время.
Выражение cron в Schedule Trigger почти всегда верное. На практике чаще всего неверным оказывается часовой пояс, в котором n8n вычисляет это выражение. Именно этот паттерн прослеживается в трёх реальных темах на форуме n8n, которые мы подробно рассмотрим в этой статье: команда в режиме Queue, пользователь из Бразилии и пользователь из Лондона, который удивлялся разнице в один час, хотя настройка его workflow была установлена на GMT. Во всех трёх случаях само выражение cron было корректным, причина крылась на уровень глубже.
Согласно официальной документации по Schedule Trigger узел использует иерархию часовых поясов с несколькими уровнями, и именно здесь возникает большинство неожиданностей. Если вы понимаете, как n8n разрешает эти уровни, вы можете избежать почти всех ошибок с часовыми поясами ещё до того, как они попадут в продакшен. Актуально на: июль 2026.
В пользовательском режиме Schedule Trigger, согласно документации, принимает классическое выражение cron из шести полей, где шестое, необязательное поле отвечает за секунды, за ним следуют минута, час, день месяца, месяц и день недели. Документация приводит справочную таблицу с распространёнными шаблонами:
Для тестирования сам n8n рекомендует заранее проверить выражение на crontab.guru, правда без необязательного столбца секунд, поскольку этот инструмент знает только пять полей. Уже этот шаг помогает исключить синтаксические ошибки ещё до того, как вы столкнётесь с ловушками часовых поясов. Само выражение почти во всех публично обсуждаемых проблемах оказывается безобидным, проблема начинается только после этого, с вопроса, в каком часовом поясе n8n на самом деле вычисляет это выражение.
n8n устанавливает чёткий порядок приоритета для часового пояса. Если часовой пояс задан в самом workflow, применяется он. Если он отсутствует, n8n использует часовой пояс instance. Для self hosted инсталляций значением по умолчанию является не UTC и не часовой пояс вашего сервера, а, согласно документации, `America/New_York`. В n8n Cloud система пытается автоматически определить часовой пояс владельца аккаунта, но при неудачном определении возвращается к GMT.
На странице о частых проблемах Schedule Trigger именно этот механизм описан как самый частый источник ошибок, и названы два рычага настройки: на уровне workflow часовой пояс можно изменить через три точки в правом верхнем углу канваса, затем Settings и параметр Timezone. Глобально для всей instance на self hosted инсталляциях вместо этого задаётся переменная окружения `GENERIC_TIMEZONE`. Важно: эта переменная действует на instance, а не автоматически на каждый отдельный процесс, относящийся к этой instance, как показывает первый случай ниже.
В теме "Schedule Trigger executing at wrong time" пользователь описывает еженедельный триггер, который должен был запускаться по воскресеньям в 3 часа ночи PST, но фактически срабатывал в 19 часов. И настройка workflow, и часовой пояс инсталляции были правильно установлены на PST, старый узел Cron даже работал параллельно без ошибок. Пользователь сам нашёл решение: "We use n8n in queue mode - and it turns out, I forgot to set the timezone parameters on the workers!!!" У главной instance был правильный часовой пояс, а у отдельных worker-подов в Kubernetes нет. После установки переменной окружения TZ на worker-деплойментах тестовый workflow запустился "on the dot", как подтвердил пользователь. Тот, кто использует n8n в режиме Queue, должен задавать часовой пояс на каждом отдельном компоненте, а не только на главной instance.
В теме "Schedule Trigger - what's the time zone?" пользователь из Бразилии (UTC-3) сообщает о разнице ровно в два часа: триггер, запланированный на 11 часов, сработал вместо этого в 13 часов. Причиной было просто не переопределённое значение по умолчанию `America/New_York`, которое n8n применяет к self hosted инсталляциям, если никто явно не настроил ничего другого. В качестве решения были названы два способа: либо изменить часовой пояс прямо в workflow через Settings, либо задать его глобально через `GENERIC_TIMEZONE` в файле Docker Compose или в Docker-образе. Тот, кто настраивает новую инсталляцию n8n, должен подумать об этой переменной с самого начала, а не добавлять её только после первого неверно сработавшего триггера.
В теме "Schedule Trigger and Confusion Over Time Zone Settings" пользователь kpakfar удивлялся разнице в один час между `DateTime.now()`, которое корректно показывало лондонское время с учётом летнего времени, и Schedule Trigger, который, судя по всему, работал по настройке с обозначением GMT. Участник сообщества ihortom пояснил, что триггер работал корректно по лондонскому времени, а не по буквальному обозначению "GMT 00:00". Пояснение к этому: тот, кто действительно хочет фиксированный часовой пояс без перехода на летнее время, должен явно выбрать "(GMT+00:00) GMT (no daylight saving)". Обычный вариант часового пояса, привязанный к городу, автоматически учитывает летнее время, даже если его название не сообщает об этом на первый взгляд. Тот, кому нужны фиксированные времена UTC независимо от летнего времени, например для систем, которые сами работают в UTC, должен целенаправленно выбирать вариант без летнего времени, а не часовой пояс на основе города.
В NordFlux мы настраиваем workflow n8n так, чтобы cron-триггеры с самого начала работали в правильном часовом поясе, будь то на одной instance или в режиме Queue с несколькими worker. Так критичные по времени автоматизации остаются надёжными, а вы сохраняете контроль над тем, когда ваши цифровые сотрудники действительно включаются в работу. Подробнее о нашем подходе вы найдёте на n8n-автоматизации от NordFlux.
В подавляющем большинстве случаев дело не в самом выражении cron, а в часовом поясе, в котором n8n его вычисляет. Сначала проверьте настройки workflow, затем часовой пояс instance, а в режиме Queue дополнительно часовой пояс на каждом worker.
Для self hosted инсталляций значение по умолчанию согласно документации `America/New_York`. В n8n Cloud система пытается автоматически определить часовой пояс, а при неудачном определении переходит на GMT. Оба значения по умолчанию редко случайно совпадают с вашим фактическим часовым поясом.
Откройте workflow в канвасе, нажмите на три точки в правом верхнем углу, выберите Settings и настройте параметр Timezone. Эта настройка переопределяет часовой пояс instance только для этого одного workflow.
Да. Настройки часового пояса главной instance недостаточно в режиме Queue, потому что триггеры выполняются на отдельных worker-процессах. Задайте соответствующую переменную окружения TZ на каждом worker-деплойменте, иначе главная instance может быть настроена правильно, а триггер всё равно сработает не в то время.
Часовой пояс на основе города, например Лондона или Берлина, автоматически подстраивается под летнее и зимнее время. Если вместо этого вам нужно фиксированное время независимо от сезона, явно выбирайте вариант часового пояса без летнего времени, а не полагайтесь только на название.
NordFlux создаёт цифровых сотрудников для организаций: автоматизации и КИ-агентов, которые берут на себя повторяющуюся работу. Вы сохраняете контроль.
Обзор всех типов триггеров n8n: Schedule, Webhook, Polling, Manual и Chat, включая рекомендации по применению для каждого сценария.
Stuck executions в n8n можно распознать по зависшим индикаторам статуса. Вот как правильно настроить EXECUTIONS_TIMEOUT и найти причину.
По умолчанию n8n работает в часовом поясе America/New_York вместо Europe/Berlin. Вот как правильно настроить GENERIC_TIMEZONE и часовой пояс workflow.
У инстанса, workflow и воркера может быть своя часовая зона, и именно из-за этого взаимодействия возникают типичные ошибки Cron. NordFlux берет на себя сопровождаемую эксплуатацию вашего инстанса n8n и следит, чтобы запланированные workflow надежно запускались в нужное время. На первой встрече мы подробно разберем вашу настройку триггеров.
