--- title: "Redis unavailable в n8n: runbook для queue mode - Nodbot" source_url: "https://nodbot.ru/playbooks/runbook-redis-unavailable/" canonical_url: "https://nodbot.ru/playbooks/runbook-redis-unavailable/" language: "ru" content_type: "TroubleshootingGuide" section: "playbooks" generated_at: "2026-05-30" word_count_source: 1111 --- # Redis unavailable в n8n: runbook для queue mode ## AI summary Runbook для Redis unavailable в n8n queue mode: симптомы, проверки Docker, workers, EXECUTIONS_MODE, BullMQ, восстановление и профилактика. ## Best used for Страница объясняет «Redis unavailable в n8n: runbook для queue mode - Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ - Когда применять этот runbook - 1. Быстро определить масштаб инцидента - 2. Проверить состояние контейнеров - 3. Сверить переменные окружения - 4. Восстановить обработку без хаоса - 5. Что записать в incident log - Профилактика ## Source outline # Redis unavailable в n8n: runbook для queue mode Обновлено: 2026-05-29 Intent: runbook Redis unavailable: что делать, если n8n queue mode не видит Redis, workers не забирают jobs, executions зависают H1: Redis unavailable в n8n: runbook для queue mode и workers Schema: TechArticle, HowTo, FAQPage, BreadcrumbList Old word count: 655 New word count: 864 ## Короткий ответ Если Redis недоступен, n8n в queue mode перестаёт нормально передавать production executions в workers: новые задания могут зависать, webhook-процессы отвечают нестабильно, а очередь не уменьшается. Сначала подтвердите, что проблема именно в Redis, затем проверьте сеть Docker, имя сервиса, пароль, переменные QUEUE_BULL_REDIS_* , режим EXECUTIONS_MODE=queue и состояние workers. Не перезапускайте всё подряд без фиксации симптомов: можно потерять контекст инцидента и не понять, какие executions нужно переиграть. ## Когда применять этот runbook Используйте страницу, если n8n уже работает в queue mode или вы готовите self-hosted production с отдельными workers. В regular mode Redis обычно не является обязательной точкой отказа, поэтому симптомы будут другими. В queue mode Redis становится брокером очереди: main instance принимает запуск, кладёт job в очередь, worker забирает job и выполняет workflow. Типичные сигналы: - webhook принял событие, но downstream-действия не происходят; - executions долго висят в состоянии waiting/running; - workers запущены, но не берут задания; - в логах есть ECONNREFUSED , ETIMEDOUT , NOAUTH , READONLY или Redis connection failed ; - после деплоя часть контейнеров видит Redis, а часть — нет; - очередь растёт быстрее, чем обрабатывается. ## 1. Быстро определить масштаб инцидента Сначала разделите проблему на три зоны: Redis полностью недоступен, доступен только части контейнеров или доступен, но очередь не обрабатывается. - Признак | Вероятная зона | Первое действие - Все workers ругаются на Redis | Redis/service/network | проверить контейнер Redis и DNS-имя - Только один worker не работает | env конкретного worker | сравнить .env и compose-сервис - Redis доступен, но jobs не уходят | worker/concurrency | проверить workers, лимиты и ошибки workflow - Webhooks падают сразу | main/webhook processor | проверить main instance и EXECUTIONS_MODE - Ошибка NOAUTH | пароль/секрет | сравнить пароль Redis во всех сервисах Зафиксируйте время начала, affected workflows, количество waiting/running executions и последние изменения: деплой, обновление Docker Compose, смена паролей, миграция сервера, рестарт Redis. ## 2. Проверить состояние контейнеров Для Docker Compose начните с базовой картины: ``` docker compose ps docker compose logs --tail=100 redis docker compose logs --tail=100 n8n docker compose logs --tail=100 n8n-worker ``` Если Redis контейнер перезапускается, не лечите n8n. Сначала выясните, почему падает Redis: нет места на диске, неверная команда запуска, corrupted volume, memory limit, пароль, permissions. Проверьте доступ из сети, где живут n8n и worker: ``` docker compose exec n8n sh -lc 'nc -vz redis 6379 || true' docker compose exec n8n-worker sh -lc 'nc -vz redis 6379 || true' ``` Если redis не резолвится, чаще всего причина в имени сервиса, разных Docker networks или попытке использовать localhost . Внутри контейнера localhost — это сам контейнер, а не соседний Redis. ## 3. Сверить переменные окружения Самый частый production-баг — main instance и workers запущены с разными Redis-настройками. Проверьте не только наличие переменных, но и одинаковость значений. Минимальный набор для queue mode обычно включает: ``` EXECUTIONS_MODE=queue QUEUE_BULL_REDIS_HOST=redis QUEUE_BULL_REDIS_PORT=6379 QUEUE_BULL_REDIS_PASSWORD=... N8N_ENCRYPTION_KEY=... ``` Важно: N8N_ENCRYPTION_KEY должен совпадать у main и workers. Иначе worker может получить execution, но не сможет корректно расшифровать credentials. Проверьте: - EXECUTIONS_MODE=queue задан в main и worker; - Redis host — это имя сервиса или реальный endpoint, а не localhost ; - пароль одинаковый в Redis и в n8n-сервисах; - workers не используют старый .env после деплоя; - переменные не переопределяются в CI/CD или systemd; - staging и production не смотрят в один Redis. ## 4. Восстановить обработку без хаоса Если Redis недоступен из-за упавшего контейнера, восстановите Redis и только затем перезапускайте workers. Если Redis доступен, но workers зависли, перезапуск workers может быть безопаснее, чем перезапуск main instance. Рекомендуемый порядок: - Остановить источник лавины, если он создаёт тысячи событий: временно отключить внешний webhook, cron или провайдера. - Поднять Redis и убедиться, что он отвечает из main и worker. - Перезапустить workers, а не весь стек сразу. - Проверить, уменьшается ли очередь. - Проверить failed executions и понять, какие нужно replay. - Вернуть входящий трафик. Не очищайте Redis руками, если не понимаете, какие jobs там лежат. Для части бизнес-процессов потеря job хуже, чем задержка. ## 5. Что записать в incident log После восстановления зафиксируйте: - точное время начала и окончания; - affected workflows и внешние системы; - количество зависших, failed и переигранных executions; - root cause: сеть, пароль, resource limit, deploy, Redis crash; - что было сделано для восстановления; - какие алерты сработали или не сработали; - какие проверки добавить в readiness checklist. Хороший инцидентный отчёт помогает не спорить через месяц, почему Redis снова стал единственной точкой отказа. ## Профилактика - Запустить отдельный Redis для production n8n, не общий с тестами. - Мониторить доступность Redis, память, рестарты и latency. - Добавить alert на рост waiting executions. - Проверять queue mode после каждого деплоя smoke-тестом. - Хранить .env как production-конфигурацию, а не как черновик. - Документировать, где лежит пароль Redis и кто может его менять. ## FAQ Можно ли запускать queue mode без Redis? Нет, для queue mode Redis нужен как брокер очереди. Если Redis недоступен, production executions не будут стабильно попадать к workers. Почему main instance работает, а workers ничего не выполняют? Часто main и worker видят разные Redis-настройки, используют разные .env или worker не имеет правильного N8N_ENCRYPTION_KEY . Нужно ли сразу перезапускать весь Docker Compose? Не всегда. Сначала проверьте Redis и сеть. Иногда достаточно перезапустить workers после восстановления Redis. Что делать с events, которые пришли во время сбоя? Сверьте внешние источники: payment provider, CRM, очередь сообщений, logs webhook. Для критичных событий нужен replay по event_id или ручная сверка. ## Как применять playbook в команде Playbook «Redis unavailable в n8n» должен быть понятен человеку, который не писал workflow. Поэтому в нём нужны входной сигнал, частота запуска, критерий тревоги, ответственный и ожидаемое действие после срабатывания. Используйте этот материал как операционную инструкцию: что проверить, где посмотреть логи, как понять масштаб проблемы и когда эскалировать. - Слой | Что зафиксировать | Зачем - Вход | нормализованный prompt, контекст, список источников, версия промпта и ожидаемый JSON-ответ | позволяет повторить проблему без доступа к production-секретам - Контроль | validation_error_rate, token_cost, fallback_usage, human_review_rate, source_coverage | показывает деградацию раньше, чем пользователи начинают писать в поддержку - Безопасность | получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий - Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «Redis unavailable в 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": [] } } ``` ### Критерий готовности - есть понятный вход, выход и владелец процесса - проверены пустой input, повтор события и ошибка внешнего сервиса - результат логируется без секретов и персональных данных - страница связана с соседними рецептами, ошибками или playbook по теме ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.