Как настроить тайм-аут сценария n8n и проверить остановку

Заявка может остаться без статуса, документ — задержать следующий этап, а новый запуск — пересечься с ещё работающим выполнением. Чтобы тайм-аут решал эту проблему, недостаточно указать число секунд. Нужно определить, когда ожидание теряет смысл, что произойдёт при остановке и кто проверит незавершённую операцию.

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

Когда долгое выполнение становится проблемой

Не каждое долгое выполнение зависло. Внешний сервис может обрабатывать большой документ, API — отвечать медленнее обычного, а отдельная операция — занимать предусмотренное процессом время.

Предел нужен там, где дальнейшее ожидание уже мешает работе. Чтобы найти эту точку, ответьте на четыре вопроса:

1. С какого события начинается ожидание?
2. Какой результат должен получить workflow?
3. Какой следующий шаг зависит от этого результата?
4. Когда запоздалый ответ перестаёт быть полезным или создаёт новый риск?

Допустим, workflow получает заявку, отправляет данные во внешний сервис и после ответа создаёт рабочую запись. Если менеджер должен связаться с клиентом до определённого этапа процесса, тайм-аут следует соотнести с этим этапом. Само по себе «слишком долго» не задаёт требования.

Общий тайм-аут не заменяет ограничение отдельного запроса

В n8n нужно различать как минимум два уровня ожидания:

• предел выполнения всего workflow;
• тайм-аут конкретного сетевого запроса или подключения.

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

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

Общий и индивидуальный пределы workflow

В конфигурации n8n используются разные ограничения:

Официальная документация подтверждает общий тайм-аут, возможность индивидуального максимального времени выполнения и ограничитель EXECUTIONS_TIMEOUT_MAX. Но предоставленный источник не показывает, где и каким полем задаётся фактическое значение конкретного workflow. Способ настройки нужно сверить с документацией установленной версии n8n. Примерные значения из документации — это примеры конфигурации, а не рекомендуемая норма для рабочего процесса.

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

Почему workflow может остановиться позже заданного времени

Момент остановки зависит от режима выполнения. Если workflow работает в основном процессе, n8n применяет мягкий тайм-аут. Он вступает в силу после завершения текущего узла.

Это означает, что долгий узел может продолжать работу после достижения заданного предела. Такое превышение само по себе не доказывает неисправность: сначала нужно сопоставить фактическое поведение с режимом выполнения и длительностью текущего узла.

Из этого ограничения следует практический вывод: если критично ограничить ожидание внешнего API, настройте и проверьте тайм-аут самого запроса. Один предел всего workflow не гарантирует мгновенную остановку выполняющегося узла.

Как работает остановка в отдельном процессе

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

Поэтому указанное время нельзя трактовать как обещание завершить выполнение ровно в эту секунду. При проверке нужно отдельно зафиксировать:

1. момент достижения предела;
2. попытку мягкой остановки;
3. дополнительное ожидание;
4. фактический момент завершения процесса;
5. итоговый статус выполнения.

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

Что сохранить для разбора сотрудником

Одно execution в n8n соответствует одному запуску workflow. Но это определение не гарантирует, что в записи автоматически окажутся все сведения, необходимые сотруднику.

Для передачи сбоя полезно заранее определить состав контекста:

• бизнес-идентификатор заявки, документа или операции;
• идентификатор execution, если он доступен;
• время запуска;
• ожидаемый результат;
• последний подтверждённый этап;
• внешнее действие, итог которого пока неизвестен;
• ответственного и разрешённое следующее действие.

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

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

Почему обработчик тайм-аута проверяют отдельно

Error Trigger запускает связанный error workflow, когда автоматический workflow завершается с ошибкой. Но предоставленные источники не подтверждают, что отмена именно по тайм-ауту запускает Error Trigger во всех версиях, режимах и конфигурациях.

Поэтому уведомление сотрудника, регистрация инцидента и назначение ответственного — требования к будущему решению, а не свойства, которые можно считать готовыми по умолчанию. Связку «тайм-аут → error workflow → сообщение сотруднику» нужно испытать целиком.

Ручной запуск для этой проверки не подходит: документация n8n указывает, что error workflow с Error Trigger срабатывает только при ошибке автоматического выполнения. Используйте безопасный автоматический триггер. Если обработчик не запускается при нужном типе остановки, потребуется другой проверяемый способ обнаружить затянувшееся или отменённое выполнение.

Учебный пример: заявка и внешний API

Это условная демонстрация, а не клиентский кейс и не результат выполненного теста.

Workflow получает заявку, обращается к внешнему API и после ответа должен создать рабочую запись. В тестовой копии внешний вызов заменяют управляемой задержкой, которая превышает выбранный предел.

Для выполнения в основном процессе проверяют, что мягкая остановка может вступить в силу только после завершения текущего узла. Для выполнения в отдельном процессе фиксируют попытку мягкой остановки и возможное принудительное завершение после дополнительного ожидания в одну пятую тайм-аута.

Отдельный автоматический тест должен показать, запускается ли связанный error workflow при такой отмене. Пока результат не подтверждён, уведомление сотрудника остаётся требованием проекта. После остановки проверяют состояние запроса во внешнем сервисе: он мог завершиться, остаться в обработке или не начаться.

Такой тест отвечает на три разных вопроса:

• когда n8n фактически прекращает выполнение;
• что произошло с внешней операцией;
• получил ли сотрудник достаточно сведений для решения.

Как безопасно проверить тайм-аут

Используйте изолированную копию workflow без необратимых внешних действий. До запуска зафиксируйте версию и конфигурацию n8n, режим выполнения, общий тайм-аут, индивидуальное значение, верхнюю границу и ожидаемое поведение.

Порядок проверки:

1. Подготовьте безопасный автоматический триггер и управляемую задержку.
2. Запишите входные данные, время начала и ожидаемый момент достижения предела.
3. Проверьте main process: когда завершился текущий узел и когда остановился workflow.
4. Отдельно проверьте выполнение в собственном процессе: попытку мягкой остановки и дополнительное ожидание.
5. Зафиксируйте итоговый статус и доступные сведения execution.
6. Проверьте, запустился ли error workflow и дошло ли тестовое сообщение.
7. Выясните состояние внешней операции независимо от статуса n8n.
8. Сопоставьте фактический результат с ожидаемым и оформите расхождения как требования к доработке.

Приёмка относится только к исследованной версии, режиму, конфигурации и сценарию. Она не доказывает сохранность любых данных, гарантированное уведомление или безопасность повторного запуска в других условиях.

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

Тайм-аут можно считать полезным, когда команда заранее знает:

• какое ожидание допустимо;
• почему после этой точки процесс нужно остановить;
• как фактически ведёт себя выбранный режим n8n;
• где проверить результат внешнего действия;
• какие сведения получает ответственный;
• что сотрудник может сделать дальше;
• какие операции нельзя повторять без дополнительной проверки.

Для такой задачи обычно достаточно обычной автоматизации и интеграции: фиксированный сценарий ограничивает время, сохраняет контекст и передаёт исключение человеку. ИИ-агент нужен только тогда, когда системе действительно приходится выбирать следующий шаг по меняющимся данным. Чат-бот может быть каналом уведомления, но сам по себе не определяет правила остановки и восстановления процесса.

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