Управление конкурентностью (лимиты Cloud: Starter 5 / Pro 20 параллельно)

В n8n Cloud каждый тарифный план ограничивает количество workflow-выполнений, которые могут выполняться одновременно: план Starter допускает 5 параллельных выполнений, план Pro 20, а уровень Enterprise находится, согласно обзору тарифов n8n, на уровне 200 или более параллельных выполнений. При превышении лимита n8n автоматически ставит дополнительные выполнения в очередь и обрабатывает их по принципу FIFO, как только снова освобождается мощность. Для компаний, которые регулярно обрабатывают большие объемы данных, например массовые импорты, массовые рассылки или обработку длинных списков через webhook-триггеры, этот лимит является фактором, который следует знать перед созданием workflow, иначе выполнения незаметно накапливаются в очереди. По состоянию на: июль 2026.

Как работает лимит конкурентности в n8n Cloud

Согласно документации n8n по конкурентности в облаке, ограничение действует исключительно для рабочих (production) выполнений, то есть тех, которые запускаются через webhook или узел-триггер. Ручные тестовые запуски, суб-workflow и workflow обработки ошибок не учитываются и продолжают выполняться независимо от лимита. Если количество одновременных рабочих выполнений превышает значение тарифного плана, дополнительные запуски не отклоняются, а ожидают в очереди. Важно на практике: ожидающие выполнения нельзя перезапустить повторно (без retry), а тот, кто отменяет ожидающее выполнение, полностью удаляет его из очереди. После перезапуска инстанса n8n возобновляет ожидающие запуски до предела мощности и снова ставит остальные в очередь. Текущий уровень загрузки можно увидеть непосредственно на вкладке выполнений проекта или workflow.

Влияние на массовую обработку

Например, тот, кто запускает 500 записей по отдельности как отдельные выполнения через webhook, автоматически получает очередь в плане Starter после первых 5 одновременных запусков, даже если сам n8n не показывает сообщение об ошибке. Это задерживает общую обработку, но не приводит к потере данных, пока никто не отменяет ожидающие выполнения. Более критично это становится при чувствительных ко времени процессах, например когда внешняя система ожидает быстрого ответа, а очередь непредсказуемо увеличивает время реакции. Также при перезапусках инстанса (например, из-за окон обслуживания) очередь может кратковременно продолжать расти, прежде чем будет обработана.

Обходные пути через батчинг

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

• Использовать Split in Batches: записи обрабатываются группами в рамках одного запуска workflow, вместо того чтобы запускать отдельное рабочее выполнение для каждой записи. Это значительно снижает количество одновременных выполнений.
• Планировать время ожидания: узел Wait между батчами разгружает нижестоящие системы (например, API с собственными лимитами скорости) в дополнение к внутренней очереди n8n.
• Использовать суб-workflow: поскольку выполнения суб-workflow, согласно документации, не учитываются в лимите конкурентности, логику обработки можно частично структурировать так, чтобы одновременно возникало меньше рабочих выполнений верхнего уровня.
• Ограничивать частоту триггеров: при массовых загрузках имеет смысл настроить темп запускающего процесса (например, cron-задачи или предварительного импорта) так, чтобы количество одновременных вызовов webhook изначально оставалось ниже лимита тарифного плана.

Честно говоря, ни один из этих приемов не заменяет более высокий тарифный план, если постоянно требуется больше реального параллелизма. Батчинг сдвигает нагрузку во времени, но не создает дополнительную мощность.

Собственный хостинг: полный контроль над лимитом

У тех, кто эксплуатирует n8n самостоятельно, больше свободы действий: согласно документации n8n по управлению конкурентностью, ограничение по умолчанию отключено при самостоятельном хостинге и может быть целенаправленно задано через переменную окружения N8N_CONCURRENCY_PRODUCTION_LIMIT, в том числе в режиме очереди. Это означает больше контроля над собственной инфраструктурой, но и больше личной ответственности: без осознанно заданного лимита инстанс может быть перегружен при внезапном скачке нагрузки. Именно здесь начинается грамотное планирование, например при решении вопроса, подходит ли облачный тарифный план или собственная инфраструктура реальному объему данных и требованиям к контролю компании. NordFlux поддерживает именно в этой оценке в рамках консультаций по n8n.

Часто задаваемые вопросы об управлении конкурентностью в n8n

Что происходит с выполнениями, которые превышают лимит?

Они не отклоняются, а автоматически помещаются в очередь и обрабатываются в порядке поступления (FIFO), как только снова освобождается мощность.

Распространяется ли лимит также на ручные тестовые запуски?

Нет. Согласно документации, лимит конкурентности в n8n Cloud касается только рабочих выполнений через webhook или узел-триггер. Ручные выполнения, суб-workflow и workflow обработки ошибок исключены.

Могу ли я просто перезапустить ожидающее выполнение?

Нет, ожидающие выполнения нельзя перезапустить повторно (retry). Тот, кто их отменяет, полностью удаляет их из очереди, и их нужно запускать заново.

Стоит ли переходить на план Pro из-за лимита конкурентности?

Это зависит от фактического объема обработки. Тот, кто регулярно нуждается в значительно более чем 5 одновременных рабочих выполнениях, чаще ощущает задержки из-за очереди в плане Starter. Батчинг может это смягчить, но при постоянно высоком объеме он не заменяет более высокий тарифный план.