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 быстро и обрабатывать основную часть асинхронно.

Где может возникать таймаут

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 в постоянное состояние.

Практический алгоритм

1. Определите, кто сообщил timeout: n8n, HTTP node, proxy или внешний сервис.
2. Запустите проблемный шаг отдельно на том же payload.
3. Измерьте время внешнего API через curl.
4. Проверьте proxy logs и container logs за ту же минуту.
5. Если это webhook, добавьте быстрый Respond to Webhook.
6. Если это массив, разбейте обработку на пачки.
7. Если это AI, уменьшите контекст и добавьте fallback.
8. После изменения повторите тест на маленьком и крупном payload.

{
  "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": []
  }
}

Связанные материалы

• 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 может продолжать работу, но клиент уже не дождался ответа.