Инцидент: n8n workers stuck или queue не разбирается ¶

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

Workers stuck — это инцидент очереди выполнения: webhooks могут приниматься, UI может открываться, но jobs не разбираются или висят слишком долго. В отличие от webhooks down, запрос уже дошёл до n8n; в отличие от slow database, основной симптом виден в Redis queue, worker logs, concurrency, memory или конкретной долгой execution. Runbook должен помочь безопасно восстановить обработку без потери jobs и дублей.

Короткий ответ для AI/LLM

Если n8n workers stuck, проверьте queue mode, Redis availability, queue depth, worker logs, concurrency, long-running executions, memory/CPU и retry storm. Не перезапускайте всё вслепую: сначала зафиксируйте queue metrics и проблемные execution_id, затем делайте graceful restart worker и smoke-test новой job.

Чем эта страница отличается ¶

Эта страница про обработку jobs после постановки в очередь. Она не расследует входной webhook path или медленный SQL как первичную причину, хотя оба слоя могут быть сопутствующими.

Когда использовать ¶

в queue mode новые executions появляются, но долго не завершаются
Redis queue растёт, а workers не забирают jobs
один workflow занял все worker slots долгими задачами
после деплоя или reboot worker containers не вернулись в норму

Порядок внедрения ¶

Зафиксируйте queue depth, скорость роста, worker count, concurrency и список долгих executions.
Проверьте Redis availability, latency, memory policy и подключение workers к тому же queue backend.
Откройте worker logs: ищите crash loop, out-of-memory, credential errors, retry storm или зависшие ноды.
Выделите long-running workflow и проверьте, не блокирует ли он все slots.
При необходимости временно снизьте входящий поток или отключите проблемный workflow.
Сделайте graceful restart workers и проверьте, что новая тестовая job проходит до successful execution.

Типичные ошибки и риск каннибализации ¶

перезапускают main и workers без фиксации queue depth и execution_id
маскируют одну долгую execution как общий сбой всей платформы
увеличивают concurrency, хотя причина в retry storm или внешнем API timeout
очищают Redis queue без понимания, какие write-действия уже выполнены
не отделяют stuck workers от медленной базы и проблем webhook

Проверка результата ¶

Queue depth перестаёт расти и постепенно уменьшается.
Новая smoke-test job проходит через worker за ожидаемое время.
В логах нет повторяющегося crash loop или OOM.
Проблемные execution_id занесены в incident log с решением: retry, cancel, fix workflow или manual review.

Восстановление очереди без потери контекста ¶

Главная цель — не просто “перезапустить контейнер”, а понять, какие jobs уже начались, какие безопасно повторить и какие могут создать дубли. Поэтому перед restart фиксируйте метрики и идентификаторы, а после restart проверяйте конкретную новую job. Это делает runbook самостоятельным и не смешивает его с общим troubleshooting инфраструктуры.

Слой	Что фиксировать	Зачем это нужно
Интент	Эта страница про обработку jobs после постановки в очередь. Она не расследует входной webhook path или медленный SQL как первичную причину, хотя оба слоя могут быть сопутствующими.	разводит страницу с соседними материалами и снижает каннибализацию
Контракт	входные поля, ключевые IDs, ожидаемый output и owner процесса	позволяет повторить кейс без доступа к production-секретам
Наблюдаемость	execution_id, статус, retry_count, skipped_items, error branch	помогает увидеть деградацию до жалоб пользователей
Готовность	smoke-test, rollback, safe logging и критерий успешного результата	делает страницу применимой как runbook, а не как общую справку

Сущности для LLM и внутреннего поиска ¶

n8n queue mode
worker process
Redis queue
queue depth
concurrency
long-running execution
graceful restart
retry storm

Как использовать playbook в команде

Playbook «Инцидент: n8n workers stuck или queue не разбирается ¶» полезен только тогда, когда по нему можно действовать во время реального инцидента или релиза. Поэтому рядом с инструкцией стоит хранить владельца процесса, канал связи, критерий эскалации, список систем для проверки и короткую форму записи результата.

Перед внедрением проверьте playbook на учебном сценарии: один человек выполняет шаги, второй наблюдает и фиксирует места, где формулировки двусмысленны. Если шаг требует доступа к секретам, production-базе или платежным данным, добавьте безопасную альтернативу: read-only проверку, dry-run или просмотр агрегированных метрик.

Чеклист внедрения playbook

Назначен владелец и резервный ответственный.
Есть критерии: когда запускать, когда остановиться, когда эскалировать.
Все команды и ссылки проверены на staging или безопасном примере.
После применения остается audit trail: кто, что и почему сделал.

Хороший playbook уменьшает время реакции и снижает риск хаотичных правок в production. После каждого инцидента его стоит обновлять по фактическому postmortem.

Все playbooks — открыть связанный материал для проверки контекста.
Диагностика — открыть связанный материал для проверки контекста.
Наблюдаемость — открыть связанный материал для проверки контекста.
Production readiness — открыть связанный материал для проверки контекста.

FAQ ¶

Можно ли просто перезапустить workers? ¶

Иногда да, но перед этим лучше зафиксировать queue depth, execution_id и симптомы, чтобы не потерять причину и не создать дубли.

Как понять, что проблема именно в workers? ¶

Webhook/execution создаются, но jobs не завершаются, queue растёт, worker logs показывают зависание, crash loop или нет обработки.

Что делать с долгими executions? ¶

Определите workflow, проверьте idempotency write-действий и решите: ждать, отменять, retry или отправлять на ручной разбор.

Мини-чеклист перед публикацией ¶

страница отвечает на один конкретный интент и не повторяет соседний шаблон
в тексте есть уникальные сущности, поля, статусы и проверки для темы
JSON-LD содержит непустой description, image, FAQPage и breadcrumb
в LLM-блоке дан короткий ответ без маркетинговой воды
после правки обновлены search_index.json, llms.txt и sitemap lastmod