Выполнение зависло: находим stuck executions, настраиваем таймауты

В n8n вы видите выполнение (execution), которое просто не завершается. Статус так и остаётся «Running» или «Waiting», хотя workflow давно должен был завершиться. Это называется зависшим, или «stuck», выполнением, и это больше, чем косметическая проблема: по умолчанию, согласно официальному справочнику по переменным execution n8n вообще не имеет ограничения по времени, EXECUTIONS_TIMEOUT по умолчанию равен -1. Без собственной настройки выполнение теоретически может работать бесконечно, блокируя ресурсы, слоты воркеров и, в режиме очереди, целые очереди.

Эта статья расскажет, как распознать зависшие выполнения, какие причины обычно стоят за этим и как с помощью EXECUTIONS_TIMEOUT и EXECUTIONS_TIMEOUT_MAX задать чёткое ограничение по времени, подходящее именно вашему инстансу. Актуально на: июль 2026.

Как распознать зависшие выполнения?

• На вкладке «Executions» статус постоянно остаётся «Running» или «Waiting», хотя сопоставимые запуски обычно завершаются за секунды или несколько минут.
• Индикатор времени выполнения продолжает расти, при этом новые записи в логах или переходы между узлами не появляются.
• В режиме очереди новые выполнения скапливаются в очереди, потому что воркер заблокирован зависшим выполнением и, согласно настройке через N8N_CONCURRENCY_PRODUCTION_LIMIT, не может запускать другие запуски параллельно.
• Сервер заметно потребляет больше оперативной памяти или CPU, и это невозможно объяснить текущей нагрузкой.

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

Типичные причины зависших выполнений

• Не задан таймаут: без собственной настройки EXECUTIONS_TIMEOUT автоматическое ограничение не действует, и один неисправный узел может держать весь запуск открытым.
• Внешние вызовы без собственного таймаута: узел HTTP Request, ожидающий очень медленный или не отвечающий API, зависает до тех пор, пока другая сторона не ответит или пока не вмешается сам n8n.
• Неправильно настроенные узлы Wait: узел Wait, ожидающий внешнее событие, которое так и не наступает, удерживает выполнение постоянно в статусе «Waiting».
• Зависшие подпотоки (sub-workflows): если ваш основной workflow вызывает подпоток, его зависание напрямую передаётся вышестоящему запуску.
• Проблемы в режиме очереди: если соединение между основным процессом и воркером нарушено, например из-за нестабильного доступа к Redis, выполнения остаются в состоянии «Running», хотя воркер их фактически уже не обрабатывает.

Правильная настройка EXECUTIONS_TIMEOUT и EXECUTIONS_TIMEOUT_MAX

Для надёжного ограничения по времени, согласно руководству по настройке таймаутов workflow, решающее значение имеют две переменные окружения:

• EXECUTIONS_TIMEOUT: задаёт стандартное ограничение по времени в секундах, которое действует для всех workflow, если не задан индивидуальный лимит. Значение по умолчанию -1, то есть отключено. Значение 3600 ограничивает каждый запуск одним часом.
• EXECUTIONS_TIMEOUT_MAX: определяет абсолютный верхний предел в секундах, который действует даже если отдельный workflow задал более высокий собственный таймаут. Согласно документации, значение по умолчанию составляет 3600 секунд.

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

Отдельные workflow могут задать в своих настройках собственный, более низкий таймаут. Однако сверху это всегда ограничено параметром EXECUTIONS_TIMEOUT_MAX, так что отдельный workflow не может превысить глобальный лимит. Таким образом вы сохраняете контроль над максимальным временем выполнения без необходимости индивидуально защищать каждый workflow.

Очистка данных о выполнениях, чтобы база данных оставалась компактной

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

• EXECUTIONS_DATA_PRUNE (по умолчанию: включено) определяет, удаляются ли завершённые выполнения автоматически вообще.
• EXECUTIONS_DATA_MAX_AGE определяет, через сколько часов старые выполнения считаются кандидатами на удаление; значение по умолчанию соответствует 14 дням.
• Активные выполнения со статусом «new», «running» или «waiting» явно исключаются из очистки, как и выполнения, которые вы пометили тегами или оценками.

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

Практический чек-лист

• Сначала проверьте на вкладке Executions, какие запуски действительно уже часами или днями находятся в статусе «Running» или «Waiting».
• Задайте EXECUTIONS_TIMEOUT реалистичным значением для ваших самых длинных регулярных workflow, добавив запас по времени.
• Задайте EXECUTIONS_TIMEOUT_MAX так, чтобы даже особенно длительные отдельные workflow не могли выполняться бесконечно.
• Для узлов с внешними подключениями, например HTTP Request или точек ожидания Webhook, проверьте, стоит ли добавить туда собственный таймаут.
• В режиме очереди также следите за соединением с Redis и загрузкой ваших воркеров, ведь зависший воркер вызывает совсем другие симптомы, чем один зависший workflow.

Если вы используете n8n как цифрового сотрудника в своей компании, правильно настроенный таймаут — часть базовой конфигурации, наравне с контролем лимитов concurrency и очисткой данных. Тот, кто однажды правильно настроит эти параметры, как правило, больше не должен вручную заниматься зависшими выполнениями. Если вам нужна поддержка в этом или вы хотите сделать свой инстанс n8n в целом более стабильным, NordFlux поможет вам в создании и эксплуатации workflow n8n.

Часто задаваемые вопросы

Что означает статус «Waiting» у выполнения (execution) в n8n?

«Waiting» означает, что выполнение в определённой точке workflow ожидает внешнего события, например ответа от узла Wait или ожидаемого вызова webhook. Если этот статус сохраняется дольше ожидаемого времени выполнения, это указывает на событие, которое так и не наступает, и выполнение фактически зависает, пока таймаут не завершит его.

Какое значение следует задать для EXECUTIONS_TIMEOUT?

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

Завершает ли EXECUTIONS_TIMEOUT выполнение немедленно?

Нет, согласно документации n8n, сначала происходит мягкое прерывание. В основном процессе n8n ждёт завершения текущего активного узла, в отдельных процессах после мягкой попытки дополнительно принудительно выполняется жёсткое прерывание спустя короткое время ожидания. Таким образом, переход происходит поэтапно, а не резко.

Может ли отдельный workflow иметь таймаут выше, чем разрешает EXECUTIONS_TIMEOUT_MAX?

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

Удаляются ли зависшие выполнения из базы данных автоматически?

Нет, пока они активны. n8n явно исключает из автоматической очистки через EXECUTIONS_DATA_PRUNE выполнения со статусом «new», «running» или «waiting». Поэтому действительно зависшее выполнение сохраняется до тех пор, пока настроенный таймаут не завершит его или вы не отмените его вручную.