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 полностью недоступен, доступен только части контейнеров или доступен, но очередь не обрабатывается.

Зафиксируйте время начала, 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.

Рекомендуемый порядок:

1. Остановить источник лавины, если он создаёт тысячи событий: временно отключить внешний webhook, cron или провайдера.
2. Поднять Redis и убедиться, что он отвечает из main и worker.
3. Перезапустить workers, а не весь стек сразу.
4. Проверить, уменьшается ли очередь.
5. Проверить failed executions и понять, какие нужно replay.
6. Вернуть входящий трафик.

Не очищайте 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 или ручная сверка.

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