--- title: "Rate limit в n8n: runbook для 429, retry и batch - Nodbot" source_url: "https://nodbot.ru/playbooks/runbook-rate-limit/" canonical_url: "https://nodbot.ru/playbooks/runbook-rate-limit/" language: "ru" content_type: "TroubleshootingGuide" section: "playbooks" generated_at: "2026-05-30" word_count_source: 1050 --- # Rate limit в n8n: runbook для 429, retry и batch ## AI summary Runbook для rate limit в n8n: что делать при 429, как читать Retry-After, снизить batch size, настроить Wait, backoff, replay и идемпотентность. ## Best used for Страница объясняет «Rate limit в n8n: runbook для 429, retry и batch - Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ - Когда применять этот runbook - 1. Быстро остановить лавину - 2. Найти точку ограничения - 3. Починить flow control - 4. Защититься от дублей - 5. Безопасный replay - 6. Профилактика ## Source outline # Rate limit в n8n: runbook для 429, retry и batch Обновлено: 2026-05-29 Intent: runbook rate limit: 429, Retry-After, backoff, batch size, Wait node, idempotency и восстановление очереди n8n H1: Rate limit в n8n: как остановить 429-лавину и безопасно переиграть события Schema: TechArticle, HowTo, FAQPage, BreadcrumbList Old word count: 666 New word count: 829 ## Короткий ответ Rate limit в n8n нужно чинить не увеличением количества retry, а снижением давления на внешний API. Сначала остановите источник лавины, найдите workflow и node, которые получают 429 Too Many Requests , проверьте Retry-After или лимиты провайдера, уменьшите batch size и добавьте паузы. Для критичных процессов сохраняйте external_event_id , order_id или другой идемпотентный ключ, чтобы replay не создавал дубли. ## Когда применять этот runbook Используйте runbook, если внешний сервис начал отвечать 429 , rate limit exceeded , quota exceeded , too many requests , resource exhausted или похожей ошибкой. Это может быть CRM, Google Sheets, Telegram, OpenAI/LLM provider, платежный сервис, email/SMS-шлюз, маркетинговый API или внутренняя система. Типичные симптомы: - execution падает на HTTP Request, CRM, Sheets, AI или email node; - retry включён, но ошибок становится больше; - очередь растёт, потому что каждый failed item повторяется; - внешний провайдер временно блокирует token/IP/app; - часть данных записалась, часть нет; - после восстановления workflow создаёт дубли. Главная задача — не “дожать API”, а сохранить бизнес-события и вернуть контролируемую скорость обработки. ## 1. Быстро остановить лавину Если workflow продолжает отправлять запросы и каждый запрос получает 429, сначала уменьшите поток. Иначе вы только продлите блокировку. Что можно сделать в первые минуты: - Ситуация | Быстрый mitigation - Cron отправляет пачки | временно деактивировать workflow или увеличить интервал - Webhook получает много событий | включить rate limit на proxy или остановить источник - Queue mode забит заданиями | снизить worker concurrency или остановить часть workers - Retry усиливает нагрузку | временно отключить агрессивные retry - AI/API провайдер дорогой | отключить AI-ветку или перевести на manual approval Не удаляйте executions до анализа. В failed/running history могут быть payload, IDs и статусы, которые понадобятся для replay. ## 2. Найти точку ограничения Нужно понять, кто именно ограничивает запросы: сам API, аккаунт, OAuth app, IP, token, endpoint, project или конкретный метод. Проверьте: - HTTP status и тело ответа; - есть ли header Retry-After ; - какой endpoint получает 429; - один workflow виноват или несколько; - лимит на пользователя, приложение, IP или organisation; - не попали ли staging и production в один token; - не увеличился ли batch после последнего релиза. Для каждого affected workflow запишите: node, provider, credential, endpoint, количество попыток, пример external_event_id , время первого 429 и время последнего успешного запроса. ## 3. Починить flow control Самый устойчивый паттерн — обрабатывать данные пачками и делать паузу между пачками. Минимальная схема: - Получить список items. - Отфильтровать только новые или изменённые. - Разбить на batch. - После каждого batch поставить Wait. - При 429 читать задержку, если provider её отдаёт. - Failed items складывать в отдельный журнал. - Replay запускать отдельно, не в основном потоке. Пример правил: ``` batch_size = 20 pause_between_batches = 10-30 seconds max_retry_attempts = 3 retry_strategy = exponential backoff idempotency_key = external_event_id или provider_object_id ``` Если API возвращает Retry-After , используйте его как минимум ожидания. Если такого header нет, берите conservative backoff и не пытайтесь угадать лимит “на глаз”. ## 4. Защититься от дублей Rate limit часто ломает процесс не из-за failed requests, а из-за повторного запуска. Например, CRM-лид уже создан, но n8n не получил ответ и повторил create. Поэтому важна идемпотентность. Что добавить: - external_event_id для webhook-событий; - payment_id , order_id , lead_id , message_id для бизнес-объектов; - lookup перед create; - upsert вместо create, если API поддерживает; - журнал processed_events ; - статус pending , sent , failed , replayed ; - запрет повторной обработки одного ID без ручного решения. Для платежей и CRM особенно важно не повторять side-effect без проверки текущего состояния у provider. ## 5. Безопасный replay После снятия лимита не запускайте всё одним разом. Сначала соберите список failed items и разделите их по типам: - Тип | Что делать - Не отправлялось вообще | можно replay с малым batch - Отправилось, но ответ потерян | сначала status check у provider - Создало дубль | ручная дедупликация и фиксация правила - Данные устарели | пересчитать payload перед replay - Критичный платёж/заказ | сверка вручную до повторной операции Replay должен иметь собственный лимит скорости и отдельный журнал. Хорошо, если replay workflow принимает список IDs, а не читает “всё failed за сутки”. ## 6. Профилактика - Хранить лимиты провайдеров рядом с credential/runbook. - Делать load test на staging без production-token. - Вынести batch size в переменную или config table. - Добавить alert на рост 429. - Использовать Wait/backoff по умолчанию для внешних API. - Разделить credentials для staging и production. - Документировать, кто может просить увеличение quota. ## FAQ Нужно ли включать Retry On Fail на всех node? Нет. Retry без backoff и идемпотентности может усилить аварию. Лучше ограничить попытки и складывать failed items в журнал. Что делать, если provider не отдаёт Retry-After? Используйте conservative backoff, уменьшите batch size и проверьте документацию provider. Не пытайтесь параллелить запросы, пока лимит не понятен. Почему после 429 появляются дубли? Потому что первая операция могла выполниться, но ответ до n8n не дошёл. Перед повтором нужен status check или lookup по внешнему ID. Что важнее: быстрее обработать очередь или не создать дубли? Для CRM, платежей, заказов и уведомлений важнее идемпотентность. Быстрый replay без проверки часто дороже, чем задержка. ## Как применять playbook в команде Playbook «Rate limit в n8n» должен быть понятен человеку, который не писал workflow. Поэтому в нём нужны входной сигнал, частота запуска, критерий тревоги, ответственный и ожидаемое действие после срабатывания. Используйте этот материал как операционную инструкцию: что проверить, где посмотреть логи, как понять масштаб проблемы и когда эскалировать. - Слой | Что зафиксировать | Зачем - Вход | входной item по теме «Rate limit в n8n»: источник события, внешний ID, время получения и нормализованные поля | позволяет повторить проблему без доступа к production-секретам - Контроль | successful_executions, skipped_items, retry_count, error_branch_usage, manual_override_count | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | принять happy path за production-готовность и не проверить повторы, пустые входы, откат и наблюдаемость | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Rate limit в n8n» | делает статью пригодной для runbook, а не только для чтения ### Пример безопасного входного контракта ``` { "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": "..."} } ``` ### Критерий готовности - есть понятный вход, выход и владелец процесса - проверены пустой input, повтор события и ошибка внешнего сервиса - результат логируется без секретов и персональных данных - страница связана с соседними рецептами, ошибками или playbook по теме ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.