Rate limit policy n8n: лимиты, retry и backoff ¶

Обновлено: 2026-05-29

Короткий ответ ¶

Rate limit policy в n8n описывает, как workflow ведёт себя при лимитах API: сколько запросов можно делать, когда ждать, когда повторять, как уменьшать batch size и как не создавать дубли при retry. Без такой политики сценарий может работать на 10 тестовых строках, но падать на 10 000 контактов, блокировать CRM, тратить лишние AI-токены или получать бесконечные 429.

Когда нужна политика лимитов ¶

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

Признаки, что нужна отдельная политика:

• API возвращает 429 или throttling;
• workflow обрабатывает списки, CSV, заказы, сообщения или тикеты пачками;
• используется CRM, Google Sheets, Telegram, email, payment API или AI provider;
• есть retry после ошибок;
• workflow может запускаться параллельно;
• один сбой создаёт дубли во внешней системе.

1. Сначала узнайте лимит, а не угадывайте ¶

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

Запишите:

Не полагайтесь только на успешный тестовый запуск. Тест с одной строкой не показывает, что будет при очереди из тысячи событий.

2. Проектируйте workflow под контролируемый поток ¶

Худший паттерн: взять массив из 5000 items и отправить HTTP Request для каждого без паузы, batch size и retry policy. Такой workflow быстро ловит 429 и часто создаёт частично обработанные данные.

Лучше:

• разбивать данные на batch;
• вставлять Wait между batch или отдельными запросами;
• ограничивать параллельность;
• использовать upsert вместо create;
• писать progress log;
• сохранять cursor/checkpoint;
• отдельно обрабатывать failed items;
• не повторять write-запрос без идемпотентного ключа.

Для больших задач делайте workflow возобновляемым: если он упал на 760-й строке, команда должна продолжить с 761-й, а не запускать всё заново.

3. Retry, backoff и Wait ¶

Retry помогает только для временных ошибок. Если payload невалидный или credential не имеет прав, retry просто создаст шум.

Если провайдер возвращает Retry-After, используйте его как источник правды. Если нет — начинайте с консервативной паузы и увеличивайте её при повторных 429.

4. Идемпотентность перед retry ¶

Retry write-операций без идемпотентности опасен. Провайдер мог создать объект, но ответ не дошёл до n8n. Повторный запрос создаст дубль.

Для write-действий используйте:

• external_event_id от webhook;
• order_id, payment_id, ticket_id, lead_source_id;
• upsert вместо create;
• поиск существующего объекта перед созданием;
• unique field в CRM/БД;
• Idempotency-Key, если API поддерживает;
• журнал обработанных событий.

Правило: перед повторной записью workflow должен знать, был ли объект уже создан.

5. Лимиты AI-провайдеров ¶

AI workflow имеет два вида лимитов: технические requests/tokens и бюджетные лимиты. Если отправлять каждое сообщение в дорогую модель без фильтра, проблема будет не только в 429, но и в счёте.

Проверьте:

• нужен ли AI для каждого item;
• можно ли предварительно фильтровать простые случаи;
• есть ли token budget на workflow;
• сохраняется ли prompt version;
• есть ли кеширование ответов для одинаковых запросов;
• ограничено ли количество tool calls в Agent;
• есть ли human approval перед массовыми действиями.

Для RAG отдельно контролируйте количество retrieved chunks и длину контекста.

6. Queue mode и параллельность ¶

Если n8n работает в queue mode с несколькими workers, рост числа workers может ускорить обработку, но также быстрее упереться во внешние лимиты. Масштабирование n8n не отменяет лимиты CRM или AI API.

Проверьте:

• сколько workflow могут одновременно обращаться к одному API;
• есть ли общий лимит на credential или app;
• не запускаются ли несколько копий одного batch-процесса;
• нужен ли глобальный rate limiter на уровне Redis/proxy/внешнего сервиса;
• видно ли в логах, когда очередь растёт из-за throttling.

Иногда правильное решение — не добавить worker, а уменьшить concurrency и сделать обработку предсказуемой.

7. Runbook при массовых 429 ¶

Если API начал возвращать 429:

1. Остановите автоматические повторные запуски, если они усиливают нагрузку.
2. Зафиксируйте endpoint, credential, workflow, время и объём запросов.
3. Проверьте headers: Retry-After, reset, remaining.
4. Уменьшите batch size или увеличьте Wait.
5. Переведите часть событий в очередь/manual review.
6. Проверьте, не идут ли параллельные workflow в тот же API.
7. После восстановления обработайте backlog с checkpoint, а не полным перезапуском.

FAQ ¶

Retry On Fail решает все rate limits?
Нет. Retry помогает при временной ошибке, но без batch size, Wait, идемпотентности и понимания лимитов он может усилить проблему.

Что лучше: Wait или уменьшить batch size?
Обычно нужно оба: batch ограничивает объём, Wait задаёт темп. Для провайдеров с жёстким лимитом ориентируйтесь на Retry-After и документацию API.

Можно ли просто добавить больше workers?
Для внутренних очередей — иногда да. Для внешнего API это может ухудшить ситуацию, потому что лимит провайдера останется тем же.

Как безопасно повторить failed items?
Сначала проверьте idempotency key или внешний ID. Затем повторяйте только failed items, а не весь исходный список.

{
  "source": "manual|webhook|schedule|api",
  "external_id": "stable-id-from-source",
  "received_at": "2026-05-29T10:00:00Z",
  "payload_version": "v1",
  "dry_run": true,
  "audit": {"workflow_id": "...", "execution_id": "..."}
}