Workflow работает по кнопке, но сам не запускается утром? В n8n для этого нужен Schedule Trigger и опубликованная версия схемы. Настроим безопасный пример, увидим настоящие автоматические выполнения в журнале, остановим таймер и заменим тестовый интервал ежедневным расписанием.
Результат инструкции
Соберём два узла: Schedule Trigger → Record Run. Первый запускает схему каждые 30 секунд, второй записывает статус, время, часовой пояс и ID выполнения. Результат остаётся в истории n8n: никаких писем, платежей или запросов к чужим API. После проверки подготовим запуск в 09:00 по Москве.
AI-модель здесь не нужна: расписание - обычная автоматизация. Это основа для будущей выгрузки, отчёта или проверки данных, но учебная схема сама их не создаёт.
Что понадобится
- Работающий n8n и доступ к созданию и публикации нового workflow. Проверено на локальной версии 2.42.4.
- Отдельный пустой workflow. Не проводите тест каждые 30 секунд на рабочей рассылке или платном AI-запросе.
- Для локальной установки - запущенный контейнер n8n и включённый компьютер без сна. Открывать доступ к нему из интернета не требуется.
- Около десяти минут. Аккаунты сторонних сервисов, API-ключи и платная подписка для этой схемы не нужны.
Установить n8n локально через Docker
Шаг 1. Создайте отдельный workflow
Откройте n8n → Overview → Create workflow. Должен появиться пустой холст. Используйте новую схему, а не копию рабочего процесса с действующими credentials: через несколько шагов мы включим автоматический запуск.
Шаг 2. Импортируйте учебную схему
Скачать n8n-schedule-demo.json
Скопируйте весь текст файла, щёлкните свободное место пустого холста и нажмите Ctrl+V. Должны появиться два соединённых узла Schedule Trigger и Record Run, имя схемы - ezgpt-schedule-demo. Если узлы не помещаются на экране, нажмите Zoom to Fit.
В файле нет credentials и внешних действий; он не должен включать таймер сам при импорте. Но настройки всего workflow при вставке на холст могут не перенестись: в нашем тесте часовой пояс остался от экземпляра n8n. Поэтому следующий шаг обязателен, даже если в JSON написано Europe/Moscow.
Шаг 3. Задайте часовой пояс workflow
Откройте More actions рядом с названием workflow → Settings. В Timezone выберите Europe/Moscow и сохраните настройки. Это запуск по московскому времени; для другого региона выберите его часовой пояс, а не меняйте часы на компьютере.
В нашем экземпляре значение по умолчанию было Asia/Yekaterinburg. При таком значении «09:00» означало бы девять утра в Екатеринбурге. Если Timezone не задан отдельно, используется часовой пояс экземпляра n8n.
Шаг 4. Проверьте тестовый интервал
Дважды щёлкните значок Schedule Trigger. В Parameters → Trigger Rules оставьте одно правило: Trigger Interval = Seconds, Seconds Between Triggers = 30. Не добавляйте второе правило рядом: оно станет ещё одним расписанием запуска, а не ограничением первого.
Закройте параметры. На этом этапе автоматических выполнений ещё нет: настройка узла и публикация workflow - разные действия. Интервал в 30 секунд нужен только для быстрой проверки.
Шаг 5. Проверьте, что записывает Record Run
Откройте Record Run. Это Edit Fields, переименованный для ясности. Mode = Manual Mapping, Include Other Input Fields выключен. Все четыре поля имеют тип String. status задан обычным текстом ok. Для остальных трёх включён режим Expression:
Поле started_at получает время от Schedule Trigger:
{{ $json.timestamp }}Поле timezone показывает часовой пояс выполнения:
{{ $now.zoneName }}Поле execution_id получает уникальный ID этой записи в истории n8n:
{{ $execution.id }}Это ID выполнения n8n, не идентификатор заказа и не защита от повторной обработки бизнес-операции. До запуска интерфейс может показывать для него подсказку filled at execution time.
Шаг 6. Запустите всю схему вручную
Закройте узел и нажмите Execute workflow на холсте. Оба узла должны завершиться успешно. Откройте Record Run → OUTPUT → JSON. Вот фактический результат нашего первого ручного выполнения:
[
{
"status": "ok",
"started_at": "2026-10-09T14:48:22.367+03:00",
"timezone": "Europe/Moscow",
"execution_id": "17"
}
]У вас будут другая дата и другой ID. Проверяйте status = ok, timezone = Europe/Moscow, смещение +03:00 в started_at и непустой execution_id. Ручной запуск выполняется сразу: он не ждёт очередных 30 секунд и не доказывает, что таймер включён.
Шаг 7. Включите сохранение результатов
Снова откройте настройки workflow. Для Save successful production executions выберите Save. Убедитесь, что Save failed production executions и Save manual executions тоже позволяют сохранять результаты. Сохраните настройки.
Так в журнале останутся данные проверки, а не только сообщение на холсте. Для реальной работы отдельно настройте срок хранения и очистку истории: частый таймер быстро создаёт много выполнений. В этой схеме нет конфиденциальных данных.
Шаг 8. Опубликуйте тестовую версию
Нажмите Publish вверху справа. В окне публикации можно назвать версию schedule-30-second-test, затем подтвердите Publish. В нашем интерфейсе после этого появилась отметка Published. Только теперь начинается автоматический запуск.
В проверенной версии редактор автоматически сохраняет изменения в черновик. Это не то же самое, что публикация: запущенный таймер использует опубликованную версию. В старых версиях интерфейс может показывать переключатель Active; эта инструкция проверена с Publish.
n8n: сохранение и публикация workflow
Шаг 9. Найдите два автоматических выполнения
Перейдите во вкладку Executions этого workflow. Включите Auto refresh и подождите до 90 секунд. Должны появиться как минимум две новые записи со статусом Succeeded, без повторного нажатия Execute workflow.
Откройте каждую запись и Record Run → OUTPUT → JSON. В нашей проверке ID 18 содержал started_at = 2026-10-09T14:49:30.002+03:00, а ID 19 - 2026-10-09T14:50:00.001+03:00. Интервал около 30 секунд, ID разные, статус ok. Это и есть проверка настоящего расписания.
В списке Executions браузер показывал 16:49:30 по местному времени Екатеринбурга, а внутри JSON - 14:49:30 по Москве. Это один момент времени. Не меняйте рабочий часовой пояс только потому, что часы списка отличаются: сравнивайте timestamp со смещением и поле timezone.
Шаг 10. Остановите тестовый таймер
Откройте стрелку справа от Published → Unpublish и подтвердите действие. Должна снова появиться кнопка Publish. Запишите ID последнего выполнения, подождите 90 секунд с Auto refresh и проверьте, что новых автоматических записей нет.
В нашем тесте последняя автоматическая запись была ID 26; после отключения новых запусков по расписанию не появилось. Если в момент отключения выполнение уже началось, оно может завершиться позже. Unpublish прекращает новые production-запуски, но не является кнопкой отмены уже выполняющейся операции.
Не удаляйте историю ради остановки: она нужна для проверки и не управляет таймером. Закрытие вкладки браузера тоже не останавливает опубликованный workflow на работающем сервере.
Шаг 11. Замените интервал запуском в 09:00
В Editor откройте Schedule Trigger. Измените единственное правило: Trigger Interval = Custom (Cron). В поле Expression, оставив его в режиме Fixed, вставьте:
0 9 * * *Это каждый день в 09:00 по часовому поясу workflow. Здесь пять полей: минуты, часы, день месяца, месяц, день недели. Ноль означает нулевую минуту, девятка - час, звёздочки - любое допустимое значение. Не вставляйте дополнительные кавычки.
Для запуска только с понедельника по пятницу используйте вместо него:
0 9 * * 1-5Выберите один вариант. В n8n также допускается шестое поле секунд в начале, поэтому не добавляйте его случайно. Название поля Expression здесь относится к cron-строке; переключать её в JavaScript Expression не требуется.
Шаг 12. Проверьте новый режим и решите, включать ли его
Закройте узел, выполните Execute workflow и снова проверьте четыре поля Record Run. Правильное cron-выражение должно позволить ручной запуск. Это проверка схемы и корректности записи, но не доказательство будущего выполнения ровно в 09:00.
Для ежедневного запуска этой безопасной схемы нажмите Publish и подтвердите новую версию. В следующий назначенный момент проверьте новую запись в Executions и московское время в JSON. Если сейчас время уже позже 09:00, ежедневное правило ждёт следующего дня, а правило будней - следующего подходящего рабочего дня.
Если пример больше не нужен, оставьте workflow неопубликованным. Наша редакционная схема после проверки ежедневного cron осталась отключённой. Перед включением настоящего отчёта сначала проверьте его ручным запуском на тестовых данных.
Если расписание не работает
| Симптом | Что проверить | Что должно быть |
|---|---|---|
| Есть только ручной запуск | Статус публикации workflow | Published, новые записи без кнопки |
| Запуск есть, но данных не видно | Сохранение успешных выполнений | Save и новый результат в Executions |
| Время отличается на два часа | Timezone workflow и timestamp | Europe/Moscow, смещение +03:00 |
| Таймер запускается слишком часто | Количество правил и интервал | Одно нужное правило |
| После правки работает старый режим | Опубликована ли новая версия | Повторная публикация после правки узла |
| Cron выдаёт ошибку | Число полей и допустимые значения | Например, 0 9 * * *, часы от 0 до 23 |
Проверка перед рабочим запуском
- Два автоматических выполнения имеют разные ID и ожидаемый интервал.
- Timezone явно задан, время результата проверено со смещением UTC.
- Тестовое правило на 30 секунд заменено, а не дополнено вторым правилом.
- Нужная версия опубликована; ненужный пример отключён.
- n8n работает в назначенное время, история успешных и ошибочных запусков сохраняется.
На локальном компьютере расписание не выполнится, если n8n остановлен или компьютер спит. Не рассчитывайте, что обычный запуск после простоя автоматически воспроизведёт все пропуски: это зависит от конфигурации планировщика. Для важной ежедневной задачи нужен контроль пропусков и ошибок.
Если обработка занимает больше времени, чем интервал, заранее продумайте параллельные запуски и повторную обработку. Сам Schedule Trigger не делает отправку письма, запись в CRM или оплату идемпотентной. Не подключайте к 30-секундному тесту платежи, массовые рассылки и удаление данных.
Следующий пример: выгрузить данные в CSV
Что проверено редакцией
9 октября 2026 года пример проверен в локальном n8n 2.42.4. Новый workflow создан через редактор; после вставки часовой пояс задан отдельно. Ручной запуск успешен. Опубликованное правило на 30 секунд создало девять успешных автоматических выполнений с московским временем и разными ID. После Unpublish новых запусков по расписанию не было. Режим Custom (Cron) с 0 9 * * * успешно выполнен вручную; библиотека cron установленной версии проверила следующий момент для ежедневного правила и правила будней, а некорректное значение часа 25 отклонила. Запуск следующего утра, Cloud, пропуски при сбоях и отправка рабочих данных не тестировались. Существующие workflows не изменялись. Обложка - редакционная иллюстрация.
Частые вопросы
Нужно ли публиковать workflow для Schedule Trigger?
Да, для автоматического запуска нужна опубликованная версия. Execute workflow проверяет схему вручную и работает без включённого расписания. Одного успешного ручного результата недостаточно: найдите новые выполнения в Executions, появившиеся сами.
Как запустить n8n каждый день в 09:00 по Москве?
Задайте Timezone = Europe/Moscow в настройках workflow. В Schedule Trigger выберите Custom (Cron) и Expression = 0 9 * * *. Оставьте одно правило, проверьте схему вручную и опубликуйте нужную версию.
Почему время в Executions отличается от времени JSON?
Список в браузере может отображать местное время, а timestamp узла содержит время и смещение настроенного workflow. Сравните оба момента с учётом часового пояса. Для проверки московского режима в примере ожидаются Europe/Moscow и +03:00.
Будет ли таймер работать после закрытия браузера?
Да, если опубликованный workflow и сам n8n продолжают работать. Для локальной установки должны работать контейнер и компьютер. Сон компьютера или остановка n8n мешают запуску; закрытие одной вкладки браузера его не отключает.
Как отключить расписание и не потерять workflow?
Откройте меню рядом с Published → Unpublish и подтвердите. Схема и история остаются, новые production-запуски прекращаются. Дождитесь завершения уже начавшегося выполнения и проверьте, что следующая запись не появляется. Удалять узлы или историю не нужно.
