---
title: "Schedule Trigger в n8n: cron, расписание, часовой — Nodbot"
source_url: "https://nodbot.ru/nodes/schedule-trigger/"
canonical_url: "https://nodbot.ru/nodes/schedule-trigger/"
language: "ru"
content_type: "KnowledgePage"
section: "nodes"
generated_at: "2026-05-30"
word_count_source: 1033
---

# Schedule Trigger в n8n: cron, расписание, часовой пояс и типовые ошибки

## AI summary

Как настроить Schedule Trigger в n8n: cron-выражения, запуск по времени, GENERIC_TIMEZONE, активный workflow, отчёты, синхронизация и ошибки расписания.

## Best used for

Страница объясняет «Schedule Trigger в n8n: cron, расписание, часовой — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Когда использовать Schedule Trigger
- Настройка простого расписания
- Часовой пояс: почему workflow запускается не тогда
- Cron-выражения без мистики
- Расписание и переменные
- Как не перегрузить API
- Типовые ошибки
- Что связать с Schedule Trigger

## Source outline

# Schedule Trigger в n8n: cron, расписание, часовой пояс и типовые ошибки

Обновлено: 2026-05-29

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

Коротко

Если workflow должен запускаться сам по расписанию, используйте Schedule Trigger. Если нужно поставить паузу внутри уже запущенного workflow, используйте Wait node . Если нужно пройти массив пачками и не превысить лимит API, используйте Loop Over Items .

## Когда использовать Schedule Trigger

- Задача | Пример расписания | Что важно проверить
- Ежедневный отчёт по лидам | каждый день в 09:00 | часовой пояс, права к CRM и таблице
- Проверка новых строк в Google Sheets | каждые 5 минут | дедупликация строк, лимиты API
- Рассылка дайджеста | по будням вечером | не отправлять пустой дайджест
- Синхронизация остатков | каждый час | batch size, retry, логирование ошибок
- Ежемесячная сверка платежей | 1-го числа в 02:00 | период отчёта, timezone, повторный запуск

## Настройка простого расписания

- Добавьте Schedule Trigger первой нодой workflow.
- Выберите интервал: минуты, часы, дни, недели, месяцы или custom cron.
- Укажите конкретное время, если задача должна запускаться не просто «каждые N часов», а в рабочее окно.
- Сохраните workflow.
- Включите workflow, иначе автоматический запуск не начнётся.
- Проверьте первый запуск по execution history и логам.

## Часовой пояс: почему workflow запускается не тогда

Самая частая проблема — расписание настроено на 09:00, а workflow стартует в другое время. В self-hosted n8n проверьте переменную GENERIC_TIMEZONE . Для России обычно используют, например, Europe/Moscow . Если n8n работает в Docker, значение должно быть в окружении контейнера, а не только в документации проекта.

```
environment:
  - GENERIC_TIMEZONE=Europe/Moscow
  - TZ=Europe/Moscow
```
TZ помогает контейнеру и системным библиотекам, а GENERIC_TIMEZONE важен для логики n8n. После изменения окружения перезапустите контейнер и проверьте следующий запуск.

## Cron-выражения без мистики

Custom cron удобен, когда стандартных вариантов не хватает. Примеры:

- Расписание | Cron | Комментарий
- каждый день в 09:00 | 0 9 * * * | подходит для утренних отчётов
- каждые 15 минут | */15 * * * * | осторожно с API-лимитами
- по будням в 18:30 | 30 18 * * 1-5 | для рабочих уведомлений
- 1-го числа в 02:00 | 0 2 1 * * | для сверок и закрытия периода

Перед запуском в рабочем workflow проверьте cron на простом тесте: Schedule Trigger → Set/Edit Fields → Telegram или Respond. Так проще увидеть фактическое время запуска.

## Расписание и переменные

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

## Как не перегрузить API

Schedule Trigger часто запускает массовые синхронизации. Не ставьте «каждую минуту», если дальше идут десятки HTTP-запросов. Лучше:

- забирать только изменения за период, а не всю базу;
- хранить дату последней успешной синхронизации;
- обрабатывать записи через Loop Over Items с небольшим batch size;
- добавить Wait между пачками;
- логировать последний успешный ID или timestamp.

## Типовые ошибки

- Симптом | Вероятная причина | Что сделать
- workflow не запускается сам | он сохранён, но не включён | включить workflow и дождаться следующего расписания
- запуск идёт не в то время | неверный timezone | проверить GENERIC_TIMEZONE , TZ и настройки instance
- после импорта старый cron продолжает работать | особенность активных workflow после импорта | перезапустить n8n или заново включить workflow после проверки
- API отвечает 429 | слишком частый запуск или слишком большие пачки | увеличить интервал, добавить Loop Over Items и Wait
- отчёт отправляется пустым | нет проверки количества items | добавить IF перед отправкой уведомления

## Что связать с Schedule Trigger

- HTTP Request — регулярные запросы к API.
- Loop Over Items — обработка записей пачками.
- Wait — пауза между запросами.
- Error Trigger — уведомление о проваленной синхронизации.
- RSS → Telegram digest — пример регулярного workflow.

## Проверка ноды на реальных items

Ноду или паттерн «Schedule Trigger в n8n» лучше проверять не на одном item, а на наборе входов: пустой объект, массив из нескольких items, неожиданный тип поля и повтор события. Так вы увидите, где ломается mapping ещё до подключения реального API.

Для этой страницы базовый источник данных: входной item по теме «Schedule Trigger в n8n»: источник события, внешний ID, время получения и нормализованные поля. Если нода меняет внешнюю систему, добавьте dry-run или review-ветку.

- Слой | Что зафиксировать | Зачем
- Вход | входной item по теме «Schedule Trigger в n8n»: источник события, внешний ID, время получения и нормализованные поля | позволяет повторить проблему без доступа к production-секретам
- Контроль | successful_executions, skipped_items, retry_count, error_branch_usage, manual_override_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Schedule Trigger в n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
{
  "source": "manual|webhook|schedule|api",
  "external_id": "stable-id-from-source",
  "received_at": "2026-05-29T10:00:00Z",
  "payload_version": "v1",
  "dry_run": true,
  "audit": {"workflow_id": "...", "execution_id": "..."}
}
```

### Критерий готовности

- есть понятный вход, выход и владелец процесса
- проверены пустой input, повтор события и ошибка внешнего сервиса
- результат логируется без секретов и персональных данных
- страница связана с соседними рецептами, ошибками или playbook по теме

## Production-паттерн использования ноды

Материал «Schedule Trigger в n8n: cron, расписание, часовой пояс и типовые ошибки» стоит применять как чеклист для ревью workflow. Перед использованием ноды в production уточните, какой item приходит на вход, какие поля обязательны, что происходит с пустыми значениями и как downstream-ноды узнают, что шаг завершился успешно.

Типичная ошибка в n8n — проверить ноду на одном happy-path примере и не прогнать массив items, пустой массив, дубли и ошибку внешнего сервиса. Для надежного сценария добавьте явную ветку обработки ошибок, понятное имя execution, ограничение на размер payload и логирование ключевых диагностических полей без секретов.

### Чеклист ревью

- Проверьте, сохраняется ли структура items после этой ноды.
- Опишите, какие поля добавляются, перезаписываются или удаляются.
- Добавьте тест на пустой вход, повтор и частичный сбой.
- Свяжите ноду с error branch, retry policy и наблюдаемостью.
Если нода участвует в платежах, CRM, рассылках или AI-ответах, перед включением автоматического write-действия лучше добавить dry-run режим и ручное подтверждение для спорных случаев.

### Что прочитать рядом

- Ноды n8n — открыть связанный материал для проверки контекста.
- Items и JSON — открыть связанный материал для проверки контекста.
- Диагностика — открыть связанный материал для проверки контекста.
- Review workflow — открыть связанный материал для проверки контекста.

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)
- [Сравнения](/compare/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.