Wait node в n8n: пауза, rate limits, approval и продолжение workflow ¶
Обновлено: 2026-05-29
Wait node ставит workflow на паузу и продолжает его позже: через заданное время, в конкретную дату или после внешнего события. Это не просто «sleep». Пока workflow ждёт, n8n сохраняет execution data в базу, освобождает процесс выполнения и возвращается к данным, когда наступает условие продолжения.
Когда использовать
Wait нужен для паузы внутри одного workflow: подождать ответ клиента, не превысить лимит API, дать менеджеру время на approval, дождаться webhook от платёжной системы или отложить уведомление. Для регулярного запуска по расписанию используйте Schedule Trigger.
Основные сценарии ¶
| Сценарий | Как настроить Wait | Риск |
|---|---|---|
| пауза между API-запросами | Wait на 1–5 секунд в цикле | длинные executions при больших объёмах |
| напоминание через день | Wait до даты/времени | нужна чистка старых executions |
| human approval | Wait до webhook/ответа формы | нужна защита ссылки approval |
| платёжный сценарий | Wait до callback или отдельный webhook workflow | не путать ожидание с подтверждением оплаты |
| retry после 429 | Wait + повторный HTTP Request | лучше ограничить количество попыток |
Wait для rate limits ¶
Если API допускает, например, 60 запросов в минуту, не отправляйте 500 запросов подряд. Связка выглядит так:
- получить список записей;
- разбить обработку через Loop Over Items;
- после каждого запроса поставить Wait на короткий интервал;
- на ошибках 429 увеличить задержку;
- логировать запись, на которой workflow остановился.
Для маленьких объёмов Wait в цикле подходит. Для больших интеграций лучше проектировать очередь: таблица задач, статус обработки, повторный запуск по Schedule Trigger.
Wait до даты или времени ¶
Этот режим удобен для отложенных уведомлений: «напомнить менеджеру через 24 часа, если сделка не взята», «отправить письмо утром», «проверить оплату через 15 минут». Дату лучше хранить в явном поле, например remind_at, а не собирать из разрозненных выражений в нескольких нодах.
Wait до webhook: approval и внешние callback ¶
Wait может продолжить workflow после внешнего запроса. Это полезно для approval flow: workflow отправляет менеджеру ссылку, менеджер нажимает approve/reject, внешний запрос продолжает execution. Но такой URL нужно защищать: добавляйте токен, срок действия, проверку роли и логируйте, кто принял решение.
{
"approval_id": "appr_1001",
"decision": "approve",
"manager_id": "42",
"token": "one-time-token"
}Длинные ожидания и база данных ¶
Так как n8n сохраняет данные paused execution в базу, длинные ожидания требуют аккуратности. Если у вас тысячи workflow ждут неделями, база будет расти. Для массовых сценариев лучше хранить состояние в PostgreSQL/Supabase/Data Table и запускать проверку по расписанию, а Wait использовать точечно.
Wait или отдельный workflow ¶
| Задача | Лучший вариант | Почему |
|---|---|---|
| подождать 2 секунды между запросами | Wait | просто и понятно |
| напомнить через сутки по одному лиду | Wait | сохраняется контекст исходного лида |
| ждать оплату по тысячам заказов | отдельный webhook + таблица статусов | масштабируемее и легче отлаживать |
| регулярно проверять неотвеченные заявки | Schedule Trigger | не нужны тысячи paused executions |
| ручное согласование рискованного AI-действия | Wait + approval URL | сохраняется решение человека |
Типовые ошибки ¶
| Симптом | Причина | Что сделать |
|---|---|---|
| workflow «завис» | он ждёт дату или webhook | открыть execution и проверить Wait condition |
| после обновления workflow продолжился не так | логика изменилась, а execution был поставлен на паузу раньше | не менять критичные ноды без плана для paused executions |
| approval URL сработал повторно | нет одноразового токена или статуса решения | добавить таблицу approval_id и флаг consumed |
| база растёт слишком быстро | много долгих paused executions | перенести состояние в таблицу и запускать проверку по расписанию |
Практический контекст для внедрения ¶
Эта страница полезна не как абстрактная справка, а как рабочая инструкция под использование ноды/паттерна «Wait node в n8n: пауза, rate limits, approval и продолжение workflow» в рабочем workflow, где важно понимать входные items и формат результата. Перед изменением workflow зафиксируйте источник события: входные данные по теме wait: webhook, schedule, ручной запуск или событие внешнего сервиса. Так проще отделить ошибку данных от ошибки настройки n8n и не превратить исправление в набор случайных правок.
Минимальная проверка перед публикацией workflow: один happy path, один пустой payload, один повтор события и одна ошибка внешнего сервиса. Для мониторинга используйте successful executions, skipped items, retry count, error branch usage; эти показатели быстро покажут, что сценарий работает иначе, чем ожидалось.
Что читать дальше ¶
- Loop Over Items — обработка пачками.
- Human approval flow — согласование действий человеком.
- PostgreSQL для n8n — почему база важна для paused executions.
- Tool approval для AI Agent — безопасные AI-действия.