n8n Cron не срабатывает: почему workflow не запускается по расписанию и как это исправить

mr. Cooper 6 дней назад Веб-разработка
n8n Cron не срабатывает: почему workflow не запускается по расписанию и как это исправить

Настроили триггер по расписанию в n8n - а автоматизация так и не запустилась в нужное время? Эта статья разберёт все частые причины: от неактивного workflow до проблем с часовым поясом и конфигурацией очереди. Подойдёт как для self-hosted, так и для n8n Cloud.

Что такое Cron-триггер в n8n

В n8n есть два узла для запуска workflow по расписанию: Schedule Trigger (основной, появился в версии 0.198+) и устаревший Cron. Оба используют cron-синтаксис для задания времени запуска - например, 0 9 * * 1-5 означает «каждый будний день в 9:00».

По умолчанию n8n сам выступает в роли планировщика задач и отслеживает, когда нужно запустить тот или иной workflow. Триггеры работают только пока n8n запущен и workflow активен.

Почему Cron не срабатывает: основные причины

  • Workflow не активирован (переключатель Active выключен)

  • Неправильный часовой пояс - n8n работает в UTC, а вы ввели время по Москве

  • Ошибочный cron-синтаксис - лишний или отсутствующий пробел, неверный диапазон

  • n8n запущен через n8n start без менеджера процессов - после перезагрузки сервера сервис не поднялся

  • В режиме очереди (queue mode) не запущен worker-процесс

  • Версия n8n устарела - старый узел Cron имел баги в конкретных версиях

  • Конфликт нескольких инстансов n8n, смотрящих в одну базу

Частые ошибки

Workflow в режиме просмотра, не в режиме активации. Кнопка «Execute Workflow» в интерфейсе - это ручной запуск для тестирования. Для работы по расписанию workflow должен быть сохранён и переключатель Active включён.

Неверный часовой пояс. По умолчанию n8n использует UTC. Если вы хотите запуск в 09:00 по Москве (UTC+3), в cron-выражении нужно указать 0 6 * * *, либо явно задать таймзону через переменную окружения GENERIC_TIMEZONE.

Сервис упал и никто не заметил. При self-hosted установке без systemd или pm2, после перезагрузки сервера n8n не восстанавливается автоматически. Workflow технически активен в базе, но планировщик не работает.

Пошаговое решение

Шаг 1. Проверьте, что workflow активирован

Откройте нужный workflow. В правом верхнем углу должен гореть переключатель Active. Если он серый - нажмите, подтвердите. После этого n8n зарегистрирует расписание.

Шаг 2. Проверьте cron-выражение

Используйте онлайн-валидатор (например, crontab.guru). Формат n8n: секунды минуты часы день_месяца месяц день_недели (6 полей) либо стандартный 5-польный. При использовании Schedule Trigger проще использовать визуальный редактор.

# Запуск каждые 5 минут (5-польный cron)
*/5 * * * *

# Каждый день в 08:00 UTC (= 11:00 по Москве)
0 8 * * *

# Каждый понедельник в 10:00 UTC
0 10 * * 1

Шаг 3. Выставьте часовой пояс

В файле .env или переменных окружения добавьте:

GENERIC_TIMEZONE=Europe/Moscow

После изменения - перезапустите n8n. Часовой пояс можно также задать на уровне конкретного узла Schedule Trigger в поле Timezone.

Шаг 4. Убедитесь, что n8n запущен и работает

Проверьте статус процесса:

# если используете pm2
pm2 status

# если systemd
systemctl status n8n

# если docker
docker ps | grep n8n

Шаг 5. Queue mode: запустите worker

Если n8n настроен с EXECUTIONS_MODE=queue, мало запустить main-процесс. Нужен отдельный worker:

n8n worker

Без worker триггеры срабатывают, но задачи висят в очереди бесконечно.

Шаг 6. Проверьте логи на ошибки

# Docker
docker logs n8n --tail 100

# PM2
pm2 logs n8n --lines 100

Шаг 7. Пересохраните workflow

Иногда после обновления n8n расписание «слетает». Откройте workflow, отключите Active, сохраните, снова включите - это перерегистрирует триггер.

Шаг 8. Обновите n8n

Если используете старый узел Cron - замените его на Schedule Trigger. В версиях до 0.198 было несколько известных багов с повторными запусками и часовыми поясами.

Примеры рабочих конфигураций

Docker Compose с правильным часовым поясом:

services:
  n8n:
    image: n8nio/n8n
    environment:
      - GENERIC_TIMEZONE=Europe/Moscow
      - TZ=Europe/Moscow
      - N8N_BASIC_AUTH_ACTIVE=true
    restart: unless-stopped
    volumes:
      - n8n_data:/home/node/.n8n
Systemd unit для автозапуска:
[Unit]
Description=n8n workflow automation
After=network.target

[Service]
Type=simple
User=n8n
ExecStart=/usr/bin/n8n start
Restart=on-failure
Environment=GENERIC_TIMEZONE=Europe/Moscow

[Install]
WantedBy=multi-user.target

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

Workflow активен, cron-выражение верное, но запусков нет - что ещё проверить? Проверьте логи на ошибки инициализации, убедитесь, что нет нескольких инстансов n8n с одной базой данных, и проверьте вкладку «Executions» - возможно, запуски есть, но сразу падают с ошибкой.

Как посмотреть, когда был последний запуск по расписанию? Перейдите в раздел «Executions» в левом меню. Там отображаются все прошлые выполнения с временными метками, статусами и логами каждого шага.

Можно ли задать часовой пояс для конкретного workflow, не меняя глобальные настройки? Да. В узле Schedule Trigger есть поле Timezone - укажите там нужную зону, например Europe/Moscow. Это имеет приоритет над глобальной переменной GENERIC_TIMEZONE.

Почему n8n запускает workflow дважды вместо одного раза? Чаще всего это происходит при наличии двух запущенных инстансов n8n, смотрящих в одну базу данных. Убедитесь, что запущен только один процесс. Также проверьте, нет ли дублирующего триггера внутри workflow.

После обновления n8n Cron перестал работать - как починить? Откройте каждый workflow с триггером по расписанию, отключите активацию, сохраните, затем снова включите. Это перерегистрирует триггеры в новой версии. Также стоит заменить устаревший узел Cron на Schedule Trigger.

Работает ли Cron в n8n Cloud так же, как в self-hosted? В n8n Cloud расписание управляется автоматически - не нужно следить за процессами и сервисами. Основная точка ошибок там - часовой пояс и некорректное cron-выражение.

Как протестировать Cron-триггер без ожидания нужного времени? Нажмите кнопку «Test workflow» в интерфейсе - это запустит workflow немедленно в режиме отладки. Для Schedule Trigger также доступна кнопка «Execute step» прямо на узле.

Что делать, если n8n запущен в Docker и время контейнера отличается от хоста? Передайте переменную окружения TZ=Europe/Moscow в контейнер и убедитесь, что GENERIC_TIMEZONE совпадает. Время контейнера и хоста могут расходиться, если не синхронизирован NTP на сервере.

Полезные советы и лучшие практики

  • Всегда запускайте n8n через systemd или pm2 с флагом restart: always - это гарантирует восстановление после перезагрузки сервера.

  • Явно задавайте переменную GENERIC_TIMEZONE даже если думаете, что сервер и так в нужной зоне - это исключает неочевидные ошибки.

  • Включите уведомления об ошибках (Error Workflow) - добавьте отдельный workflow, который шлёт сообщение в Telegram или email при сбое любого другого.

  • Используйте Schedule Trigger вместо устаревшего Cron-узла - он стабильнее и поддерживает timezone на уровне узла.

  • После любых изменений в конфигурации (env-переменные, обновление версии) - деактивируйте и снова активируйте workflow, чтобы триггеры перерегистрировались.

  • Мониторьте вкладку «Executions» регулярно - там сразу видно, запускается ли workflow и есть ли ошибки.

Итог

Большинство проблем с Cron в n8n решаются по простому чеклисту: workflow активен → cron-выражение валидно → часовой пояс указан явно → сервис n8n реально запущен и не упал. В queue mode дополнительно нужен worker-процесс. Если всё это проверено, а расписание всё равно не срабатывает - смотрите логи и проверяйте на дублирующиеся инстансы n8n.

Комментарии

Пока нет комментариев. Будьте первым, кто напишет.

Чтобы оставить комментарий, войдите в аккаунт.

Похожие статьи