Правильная настройка Cron и Schedule Trigger в n8n: почти всегда виноват часовой пояс

Выражение cron в Schedule Trigger почти всегда верное. На практике чаще всего неверным оказывается часовой пояс, в котором n8n вычисляет это выражение. Именно этот паттерн прослеживается в трёх реальных темах на форуме n8n, которые мы подробно рассмотрим в этой статье: команда в режиме Queue, пользователь из Бразилии и пользователь из Лондона, который удивлялся разнице в один час, хотя настройка его workflow была установлена на GMT. Во всех трёх случаях само выражение cron было корректным, причина крылась на уровень глубже.

Согласно официальной документации по Schedule Trigger узел использует иерархию часовых поясов с несколькими уровнями, и именно здесь возникает большинство неожиданностей. Если вы понимаете, как n8n разрешает эти уровни, вы можете избежать почти всех ошибок с часовыми поясами ещё до того, как они попадут в продакшен. Актуально на: июль 2026.

Как Schedule Trigger интерпретирует выражения cron

В пользовательском режиме Schedule Trigger, согласно документации, принимает классическое выражение cron из шести полей, где шестое, необязательное поле отвечает за секунды, за ним следуют минута, час, день месяца, месяц и день недели. Документация приводит справочную таблицу с распространёнными шаблонами:

• Каждые X секунд: `*/10 * * * * *`
• Каждые X минут: `*/5 * * * *`
• Ежечасно: `0 * * * *`
• Ежедневно: `0 6 * * *`
• Еженедельно: `0 12 * * 1`
• Ежемесячно: `0 0 1 * *`

Для тестирования сам n8n рекомендует заранее проверить выражение на crontab.guru, правда без необязательного столбца секунд, поскольку этот инструмент знает только пять полей. Уже этот шаг помогает исключить синтаксические ошибки ещё до того, как вы столкнётесь с ловушками часовых поясов. Само выражение почти во всех публично обсуждаемых проблемах оказывается безобидным, проблема начинается только после этого, с вопроса, в каком часовом поясе n8n на самом деле вычисляет это выражение.

Иерархия часовых поясов: instance, workflow и worker

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, как показывает первый случай ниже.

Три реальных случая с форума n8n

Случай 1: режим Queue, настроен правильно, но всё равно неверно

В теме "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.

Случай 2: Бразилия и тихое значение по умолчанию

В теме "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, должен подумать об этой переменной с самого начала, а не добавлять её только после первого неверно сработавшего триггера.

Случай 3: Лондон, летнее время и недоразумение вокруг GMT

В теме "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, должен целенаправленно выбирать вариант без летнего времени, а не часовой пояс на основе города.

Как надёжно настроить часовой пояс

• Проверить выражение cron отдельно: Заранее протестируйте чистый синтаксис на crontab.guru, без необязательного поля секунд, прежде чем заниматься часовым поясом.
• Явно задать часовой пояс workflow: Не полагайтесь на значение instance по умолчанию, а укажите часовой пояс в настройках workflow, особенно при нескольких workflow для разных целевых аудиторий или стран.
• Задать `GENERIC_TIMEZONE` при self hosting: Без этой переменной ваша instance остаётся на `America/New_York`, независимо от того, где фактически работает ваш сервер.
• Режим Queue: не забудьте про worker: Задайте часовой пояс на каждом worker-деплойменте отдельно, одной правильно настроенной главной instance там недостаточно.
• Осознанно решить вопрос летнего времени: Выбирайте часовой пояс на основе города, если летнее время должно применяться автоматически, или фиксированный вариант без летнего времени, если вам нужно точное время UTC независимо от сезона.

В NordFlux мы настраиваем workflow n8n так, чтобы cron-триггеры с самого начала работали в правильном часовом поясе, будь то на одной instance или в режиме Queue с несколькими worker. Так критичные по времени автоматизации остаются надёжными, а вы сохраняете контроль над тем, когда ваши цифровые сотрудники действительно включаются в работу. Подробнее о нашем подходе вы найдёте на n8n-автоматизации от NordFlux.

Часто задаваемые вопросы

Почему мой cron-триггер срабатывает не в то время, хотя выражение верное?

В подавляющем большинстве случаев дело не в самом выражении cron, а в часовом поясе, в котором n8n его вычисляет. Сначала проверьте настройки workflow, затем часовой пояс instance, а в режиме Queue дополнительно часовой пояс на каждом worker.

Какой часовой пояс у n8n по умолчанию, если я ничего не настраиваю?

Для self hosted инсталляций значение по умолчанию согласно документации `America/New_York`. В n8n Cloud система пытается автоматически определить часовой пояс, а при неудачном определении переходит на GMT. Оба значения по умолчанию редко случайно совпадают с вашим фактическим часовым поясом.

Как настроить часовой пояс для отдельного workflow?

Откройте workflow в канвасе, нажмите на три точки в правом верхнем углу, выберите Settings и настройте параметр Timezone. Эта настройка переопределяет часовой пояс instance только для этого одного workflow.

Нужно ли учитывать что-то ещё в режиме Queue?

Да. Настройки часового пояса главной instance недостаточно в режиме Queue, потому что триггеры выполняются на отдельных worker-процессах. Задайте соответствующую переменную окружения TZ на каждом worker-деплойменте, иначе главная instance может быть настроена правильно, а триггер всё равно сработает не в то время.

Как избежать неожиданностей из-за летнего времени?

Часовой пояс на основе города, например Лондона или Берлина, автоматически подстраивается под летнее и зимнее время. Если вместо этого вам нужно фиксированное время независимо от сезона, явно выбирайте вариант часового пояса без летнего времени, а не полагайтесь только на название.