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

Проблема, когда workflow в n8n запускается вручную, но не выполняется по расписанию, в 2026 году остаётся одной из самых частых в self-hosted установках.

Важно понимать: это почти никогда не ошибка самого workflow или cron-выражения. В большинстве случаев сбой находится на уровне инфраструктуры, планировщика или архитектуры выполнения.

Schedule Trigger в n8n не запускает workflow напрямую. Он регистрирует задачу в системном планировщике, который работает отдельно от выполнения сценария. Если регистрация не произошла или была потеряна, workflow продолжает работать вручную, но полностью перестаёт запускаться автоматически.

Почему это происходит (логика системы)

Чтобы понять проблему, важно представить цепочку выполнения.

Schedule Trigger создаёт регистрацию в планировщике. Планировщик ждёт наступления времени. После этого событие передаётся в систему выполнения. Если используется queue mode, задача уходит в Redis. Worker забирает задачу и запускает workflow.

Если ломается любой из этих этапов, автоматический запуск исчезает, при этом интерфейс может оставаться полностью рабочим.

Диагностика состояния сервиса

Первое, что нужно проверить - работает ли сам n8n как процесс.

docker ps

или

systemctl status n8n

или

pm2 status

Если процесс не активен, расписание не существует физически, даже если интерфейс открывается через прокси или кэш.

Логи как основной источник истины

В 2026 году n8n по-прежнему не всегда явно показывает причину сбоя в интерфейсе, поэтому логи остаются ключевым инструментом диагностики.

docker logs n8n --tail 200

или

journalctl -u n8n -n 200

или

pm2 logs n8n

Если проблема существует, она почти всегда фиксируется здесь. Особенно важно искать ошибки регистрации cron, проблемы с Redis или отсутствие worker-процессов.

Активация workflow и регистрация расписания

Расписание в n8n начинает работать только после активации workflow. Это базовое, но критически важное условие.

Ручной запуск через Execute Workflow не создаёт расписание и не влияет на планировщик.

После изменений workflow может возникнуть ситуация, когда старое расписание остаётся в системе, а новое не применяется. Это выглядит как “поломка cron”, хотя на самом деле проблема в регистрации триггера.

Часовой пояс (timezone mismatch)

Одна из самых частых причин некорректного поведения расписания - различие между временем сервера и временем, которое ожидает пользователь.

В self-hosted установках n8n часто работает в UTC, даже если локальная система использует другой часовой пояс.

date
echo $TZ

В Docker важно явно задавать timezone:

environment:
  - TZ=Europe/Moscow
  - GENERIC_TIMEZONE=Europe/Moscow

Если этого не сделать, расписание может “работать”, но не в ожидаемое время.

Queue mode и разделение архитектуры

При включении queue mode система разделяется на два уровня.

Основной процесс n8n отвечает за API и регистрацию задач, но не выполняет workflow. Выполнение передаётся worker-процессам.

Если worker не запущен, система выглядит полностью исправной, но ни одно расписание фактически не выполняется.

Redis как критическая зависимость

В queue mode Redis становится центральным элементом всей системы выполнения.

redis-cli ping

Ожидаемый результат:

PONG

Если Redis недоступен, задачи перестают попадать в очередь, и расписание перестаёт работать, даже если интерфейс n8n активен.

Перезапуск и потеря расписаний

После перезапуска сервера или контейнера возможна ситуация, когда n8n запускается, но часть расписаний не восстанавливается.

Это приводит к эффекту “тихого отказа”: workflow активен, интерфейс работает, но автоматические запуски не происходят.

Несколько инстансов n8n

Если используется несколько инстансов n8n с одной базой данных, возможна рассинхронизация.

Один инстанс может зарегистрировать расписание, другой - попытаться его выполнить. Без правильной архитектуры это приводит к нестабильному поведению cron-задач.

Практическая модель диагностики

В реальной работе проблему всегда нужно рассматривать как цепочку.

Сначала проверяется, работает ли сам сервис. Затем анализируются логи. После этого проверяется регистрация расписания. Далее - timezone. Если используется queue mode - worker и Redis. И только в конце проверяется cron-логика как таковая.

Важно понимать, что cron-выражение почти никогда не является реальной причиной в production-среде.

Вывод

Если n8n не запускает workflow по расписанию в 2026 году, проблема почти всегда находится вне самого workflow. Это может быть состояние сервиса, сбой регистрации Schedule Trigger, несоответствие timezone, архитектура queue mode, отсутствие worker или проблемы с Redis.

Правильная диагностика всегда строится сверху вниз - от состояния системы к механизму выполнения, а не наоборот.