--- title: "Execution timed out в n8n: таймауты workflow, HTTP — Nodbot" source_url: "https://nodbot.ru/errors/execution-timed-out/" canonical_url: "https://nodbot.ru/errors/execution-timed-out/" language: "ru" content_type: "TroubleshootingGuide" section: "errors" generated_at: "2026-05-30" word_count_source: 1182 --- # Execution timed out в n8n: таймауты workflow, HTTP Request, AI и reverse proxy ## AI summary Execution timed out в n8n: причины таймаутов, лимиты, тяжелые ноды, очереди, retries и способы стабилизировать workflow. ## Best used for Страница объясняет «Execution timed out в n8n: таймауты workflow, HTTP — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Где может возникать таймаут - Env для общего лимита workflow - HTTP Request: таймаут ноды и повторные попытки - Webhook: быстрый ответ, длинная обработка - Nginx, Traefik, Cloudflare и 504 - AI и локальные модели - Queue mode: когда execution ждёт worker - Практический алгоритм ## Source outline # Execution timed out в n8n: таймауты workflow, HTTP Request, AI и reverse proxy Обновлено: 2026-05-29 Execution timed out в n8n означает только одно: какая-то часть процесса ждала слишком долго. Но место ожидания может быть разным: весь workflow, HTTP Request, AI-нода, Webhook response, reverse proxy, внешний API, очередь workers или ручное подтверждение. Поэтому неверно сразу увеличивать общий timeout — сначала нужно понять, какой именно слой оборвал выполнение. Правильная стратегия: разделить долгую работу и быстрый ответ. Если workflow вызывается webhook-ом от платежей, CRM или формы, внешний сервис часто ждёт ответ ограниченное время. n8n может продолжать работу дольше, но клиенту нужно вернуть HTTP 200 быстро и обрабатывать основную часть асинхронно. ## Где может возникать таймаут - Слой | Пример | Как выглядит - workflow execution | общий лимит выполнения | execution прерывается после заданного времени - HTTP Request | медленный API CRM или маркетплейса | нода падает с timeout или network error - AI/LLM | локальная модель, длинный prompt, RAG | долгое ожидание ответа модели - reverse proxy | Nginx/Cloudflare не дождался backend | 504 Gateway Timeout - webhook sender | ЮKassa, Tilda, Telegram, CRM | сервис повторяет событие или считает webhook неуспешным - queue mode | execution долго ждёт свободного worker | задача висит в очереди, workers заняты ## Env для общего лимита workflow Общий timeout задаёт верхнюю границу выполнения workflow. Он полезен как предохранитель, но не должен быть способом чинить медленную архитектуру. ``` services: n8n: environment: - EXECUTIONS_TIMEOUT=900 - EXECUTIONS_TIMEOUT_MAX=3600 ``` EXECUTIONS_TIMEOUT=900 — 15 минут по умолчанию для workflow. EXECUTIONS_TIMEOUT_MAX ограничивает максимум, который можно поставить для отдельного workflow. Если выставить бесконечные лимиты, зависшие executions будут копиться и давить на базу, workers и внешние API. ## HTTP Request: таймаут ноды и повторные попытки Если падает именно HTTP Request, смотрите не только общий timeout. Проверьте: - сколько отвечает внешний API без n8n через curl ; - есть ли pagination вместо одного огромного запроса; - не отдаёт ли API 429 или 5xx перед timeout; - включён ли retry и не усиливает ли он нагрузку; - не нужен ли Wait между запросами. ``` time curl -sS -o /tmp/response.json \ -H "Authorization: Bearer $TOKEN" \ "https://api.example.ru/orders?limit=100" ``` Если прямой запрос занимает 40 секунд, не пытайтесь уложить его в webhook-response. Такой шаг лучше делать после быстрой записи события в очередь или таблицу. ## Webhook: быстрый ответ, длинная обработка Для webhooks от платёжных систем, форм и CRM безопаснее вернуть ответ быстро, а тяжёлую часть выполнять после этого. Минимальный паттерн: ``` Webhook → validate signature → записать event_id → Respond to Webhook 200 → обработка CRM/AI/файлов ``` Если внешний сервис ждёт 3–10 секунд, а ваш workflow делает RAG, PDF, CRM, Telegram и Google Sheets, отправитель почти гарантированно решит, что webhook не сработал. Потом он повторит событие, и вы получите дубли. Поэтому таймауты webhooks всегда связаны с idempotency. ## Nginx, Traefik, Cloudflare и 504 Если в n8n execution продолжается, но клиент получает 504, проблема может быть в reverse proxy. Для Nginx проверьте proxy timeout: ``` location / { proxy_pass http://n8n:5678; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 300s; proxy_send_timeout 300s; proxy_connect_timeout 60s; } ``` Увеличение proxy timeout нужно только для сценариев, где клиент действительно должен ждать результат. Для webhook-событий лучше быстрый ответ и асинхронная обработка. ## AI и локальные модели AI-ноды могут работать дольше обычных HTTP-запросов, особенно с локальными моделями, большим контекстом и RAG. Для них важно уменьшать вход, а не только ждать дольше: - ограничить количество retrieved chunks; - не передавать весь документ в prompt; - делать summarization до Agent; - ставить fallback на более быструю модель; - логировать model, prompt size и время ответа. Если локальная модель на Ollama отвечает 90 секунд, а webhook ждёт 10 секунд, архитектура должна быть асинхронной. ## Queue mode: когда execution ждёт worker В queue mode таймаут может казаться ошибкой workflow, хотя проблема в очереди: workers заняты, concurrency слишком низкая, Redis недоступен или PostgreSQL медленный. Проверяйте: ``` docker compose ps docker compose logs --tail=100 n8n-worker docker compose logs --tail=100 redis ``` Если tasks долго ждут свободного worker, увеличьте workers или concurrency, но только после проверки базы и внешних API. Больше параллельности может ускорить очередь, а может превратить 429 и timeout в постоянное состояние. ## Практический алгоритм - Определите, кто сообщил timeout: n8n, HTTP node, proxy или внешний сервис. - Запустите проблемный шаг отдельно на том же payload. - Измерьте время внешнего API через curl . - Проверьте proxy logs и container logs за ту же минуту. - Если это webhook, добавьте быстрый Respond to Webhook. - Если это массив, разбейте обработку на пачки. - Если это AI, уменьшите контекст и добавьте fallback. - После изменения повторите тест на маленьком и крупном payload. ## Ручная диагностика перед исправлением Перед тем как менять настройки по теме «Execution timed out в n8n», зафиксируйте не только текст ошибки, но и последний успешный запуск. Для n8n это критично: один и тот же симптом может появиться из-за credentials, изменения payload, лимита API, обновления версии или инфраструктурного сбоя. Рабочий порядок: изолируйте один execution, сохраните входной item без секретов, проверьте branch с ошибкой и только потом меняйте workflow. Главный риск — исправить симптом на одной ноде, но оставить первопричину в credentials, payload, лимитах API или окружении. - Слой | Что зафиксировать | Зачем - Вход | нормализованный prompt, контекст, список источников, версия промпта и ожидаемый JSON-ответ | позволяет повторить проблему без доступа к production-секретам - Контроль | validation_error_rate, token_cost, fallback_usage, human_review_rate, source_coverage | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | исправить симптом на одной ноде, но оставить первопричину в credentials, payload, лимитах API или окружении | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Execution timed out в n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "request_id": "req_demo_001", "prompt_version": "2026-05-29", "input": "краткое нормализованное сообщение пользователя", "allowed_actions": ["read", "draft", "classify"], "forbidden_actions": ["send_without_review", "change_payment"], "expected_output": { "intent": "technical|support|sales|unknown", "confidence": 0.0, "needs_human_review": true, "sources": [] } } ``` ### Критерий готовности - точный текст ошибки сохранён без токенов и персональных данных - понятно, какая нода упала первой, а какие ошибки были следствием - есть минимальный воспроизводимый workflow или тестовый execution - после исправления проверены retry, error branch и последний успешный сценарий ## Связанные материалы - Wait node и паузы - Reverse proxy для n8n - Worker sizing - Webhook idempotency ## Ответы на частые вопросы ### Что делать при Execution timed out в n8n? Сначала определить слой: общий workflow, HTTP Request, AI-нода, proxy, webhook sender или очередь. После этого менять только нужный лимит или архитектуру. ### Можно ли просто увеличить EXECUTIONS_TIMEOUT? Можно, если workflow действительно должен работать дольше. Но для webhooks и внешних событий лучше вернуть быстрый ответ и продолжить обработку асинхронно. ### Почему webhook получает 504, а execution в n8n продолжается? Чаще всего timeout сработал в reverse proxy или у отправителя webhook. n8n может продолжать работу, но клиент уже не дождался ответа. ## Production-чеклист для таймаутов execution Используйте этот блок как быстрый контроль перед публикацией workflow или изменением существующей автоматизации. Он не заменяет staging, но помогает поймать самые частые отказы заранее. - Перед запуском: найти самую долгую ноду, проверить timeout, retries, external API и размер payload. - Минимальный тест: повторить execution на малом payload и на production-подобном payload. - Типовой отказ: одна медленная внешняя API-точка блокирует весь workflow. - Что логировать: входной payload без секретов, статус внешнего API, branch ошибки, execution id и владельца процесса. Критерий готовности: сценарий проходит успешный путь, ошибочный путь и повтор события без дублей, потери данных и неконтролируемого падения execution. ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.