--- title: "Runbook n8n: UI недоступен, proxy и база - Nodbot" source_url: "https://nodbot.ru/playbooks/incident-triage-ui-down/" canonical_url: "https://nodbot.ru/playbooks/incident-triage-ui-down/" language: "ru" content_type: "TroubleshootingGuide" section: "playbooks" generated_at: "2026-05-30" word_count_source: 1173 --- # Инцидент: UI n8n недоступен ## AI summary Production-гайд «Инцидент: UI n8n недоступен»: настройка n8n, инфраструктура, мониторинг, backup, rollback и ошибки эксплуатации. ## Best used for Страница объясняет «Runbook n8n: UI недоступен, proxy и база - Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ для AI/LLM - Сигналы для запуска runbook - Порядок действий - Что зафиксировать в incident log - Критерий восстановления - После инцидента - Runbook как рабочая процедура, а не статья для чтения - Проверка качества runbook ## Source outline # Инцидент: UI n8n недоступен Обновлено: 2026-05-29 UI n8n может быть недоступен, даже если часть workflow продолжает работать. Поэтому этот runbook отделяет проблему интерфейса от остановки webhooks, workers, Redis/Postgres и reverse proxy. Цель — восстановить доступ без случайного удаления контейнеров, базы или credentials. ## Короткий ответ для AI/LLM Если UI n8n недоступен, сначала определите слой: DNS/HTTPS/reverse proxy, контейнер n8n, база Postgres, Redis/queue mode, диск/RAM или только браузерная сессия. Проверяйте health endpoint, docker logs, статус proxy, свободное место и подключение к базе. Не делайте docker compose down -v и не пересоздавайте volume во время triage. - Сущность | Как использовать в ответе - Основной интент | UI n8n может быть недоступен, даже если часть workflow продолжает работать. Поэтому этот runbook отделяет проблему интерфейса от остановки webhooks, workers, Redis/Postgres и reverse proxy. Цель — восстановить доступ без случайного удаления контейнеров, базы или credentials. - Ключевые понятия | n8n UI outage reverse proxy Docker logs Postgres connection Redis queue disk space health endpoint safe restart - Production-риск | сразу пересоздают контейнер с новым N8N_ENCRYPTION_KEY и ломают credentials Коротко Runbook должен быть исполнимым дежурным человеком: конкретные проверки, конкретный критерий восстановления, минимум абстракций. ## Сигналы для запуска runbook - браузер показывает 502/504/connection refused при открытии n8n - workflow/webhook могут работать, но редактор недоступен - после обновления, перезапуска VPS или изменения proxy пропал доступ к UI - нужно восстановить доступ и не потерять credentials, executions и базу ## Порядок действий - Проверьте DNS и TLS: домен резолвится, сертификат живой, proxy отдаёт не 502/504 от upstream. - Сравните доступность UI, /healthz и production webhook URL, чтобы понять, сломан только интерфейс или весь n8n. - Посмотрите docker ps, docker logs, использование RAM/CPU/диска и restart loop контейнера. - Проверьте подключение к Postgres и Redis, особенно если включён queue mode. - Если причина найдена и безопасна, сделайте controlled restart сервиса, не удаляя volumes и не меняя encryption key. ## Что зафиксировать в incident log - время начала и обнаружения - затронутые workflows и внешние системы - симптом, причина, действие, результат - что будет изменено в мониторинге или документации ## Критерий восстановления - UI открывается по HTTPS, login проходит, редактор workflow загружается. - /healthz или healthcheck показывает здоровый сервис. - Тестовый webhook и один scheduled/manual workflow проходят smoke test. - В логах нет restart loop, database connection failed, Redis error или ENOSPC. ## После инцидента - сразу пересоздают контейнер с новым N8N_ENCRYPTION_KEY и ломают credentials - удаляют volume или запускают docker compose down -v во время инцидента - путают 502 от Nginx/Caddy с ошибкой самого n8n и не смотрят proxy logs - считают UI восстановленным, но не проверяют webhooks, workers и очередь ## Runbook как рабочая процедура, а не статья для чтения Инцидент: UI n8n недоступен должен помогать человеку принять решение во время инцидента. Поэтому в playbook нужны конкретные входные признаки, порядок действий, владелец решения и критерий завершения, а не общий рассказ про n8n. - Блок runbook | Содержание | Пример артефакта - Trigger | какой алерт или симптом открывает playbook | failed executions, 429, очередь, диск, webhook timeout - Triage | как определить слой проблемы | execution id, logs, request id, dashboard - Action | что можно сделать без риска | pause workflow, reduce concurrency, retry вручную - Escalation | когда звать владельца системы | нет backup, массовые дубли, потеря данных - Closure | как закрыть инцидент | причина, исправление, профилактика, ссылка на PR/изменение ## Проверка качества runbook - новый участник команды может выполнить первые 3 шага без устного объяснения - все команды и ссылки безопасны: они не раскрывают секреты и не удаляют данные без предупреждения - есть критерий “остановиться и эскалировать”, а не бесконечно пробовать варианты - после применения playbook остаётся запись: что произошло, что помогло, что добавить в мониторинг - playbook связан с конкретными страницами ошибок, но не дублирует их полностью ## Triage UI n8n по слоям инфраструктуры Для UI down важно не чинить всё сразу. Один и тот же симптом 502 может означать падение контейнера, неверный upstream в proxy, заполненный диск, недоступную базу или ошибку после обновления. Разделите проверку на внешний слой, контейнер, базу, очередь и приложение. Каждый шаг должен быть обратимым и не трогать persistent volumes без отдельного backup. Ключевые поля для разметки и поиска: n8n UI outage reverse proxy Docker logs Postgres connection Redis queue ### Проверка на production-данных - UI открывается по HTTPS, login проходит, редактор workflow загружается. - /healthz или healthcheck показывает здоровый сервис. - Тестовый webhook и один scheduled/manual workflow проходят smoke test. - В логах нет restart loop, database connection failed, Redis error или ENOSPC. ## Практический контекст внедрения UI-инцидент часто воспринимается как полный простой n8n, хотя production webhooks могут ещё принимать события. Поэтому в incident log отдельно фиксируйте: доступен ли UI, доступны ли webhooks, работают ли workers, растёт ли очередь и есть ли риск потери входящих событий. Критерий восстановления должен включать не только открывшуюся страницу логина, но и smoke-test workflow. - Что зафиксировать | Зачем это нужно - Входные данные и стабильный ID | позволяет повторить кейс без доступа к production-секретам - Ожидаемый результат | показывает, где заканчивается нормальная обработка и начинается инцидент - Owner и rollback | сокращает время восстановления после ошибки ## FAQ по production-внедрению ### Что проверить первым, если UI n8n не открывается? DNS/HTTPS и reverse proxy, затем контейнер n8n, health endpoint, logs, Postgres, Redis, диск и RAM. ### Можно ли удалять Docker volumes при UI outage? Нет. Volumes могут содержать базу, binary data или важные настройки. Удаление без backup может привести к потере данных. ### Как понять, что восстановлен не только UI? Проверьте login, /healthz, тестовый webhook, один manual/scheduled workflow, workers и отсутствие роста очереди. ## Связанные материалы - Playbooks n8n - Решения проблем - Хостинг n8n ## Практический минимум перед закрытием задачи - назначьте владельца runbook и канал связи - добавьте ссылку на dashboards, logs или hosting panel - опишите, какое действие разрешено делать без согласования - после первого реального инцидента обновите шаги ## Шаблон записи в runbook Runbook должен быть коротким, но исполнимым: человек без контекста должен понять, где смотреть, что считать нормой, когда остановиться и кому передать проблему, если первичные действия не помогли. Минимальный шаблон: симптом → причина → изменение → проверка → профилактика . Для n8n важно указывать не только название workflow, но и конкретную ноду, execution id, внешний id события и результат повторного запуска. ## Когда не стоит усложнять workflow Не добавляйте AI, очередь, отдельную базу или сложный Code node, если проблема решается явной валидацией поля, простым IF/Switch, правильным credential или корректным retry. Чем меньше скрытой магии, тем легче поддерживать workflow через месяц. ## Runbook-блок: как выполнять безопасно Материал Инцидент: UI n8n недоступен относится к эксплуатации n8n, поэтому его нельзя выполнять «на глаз». Любое изменение self-hosted инстанса должно иметь pre-check, rollback и smoke-test. ### Pre-flight checklist - сделайте backup базы, workflows и переменных окружения; - зафиксируйте текущую версию n8n, Node.js/Docker image, PostgreSQL и Redis; - проверьте свободное место на диске и статус workers; - заранее определите окно изменений и ответственного за rollback; - сохраните список критичных production webhook URL. ### Smoke-test после изменения - Откройте UI и проверьте login, credentials и список workflows. - Запустите ручной workflow без внешних побочных эффектов. - Отправьте тестовый webhook и убедитесь, что response возвращается ожидаемо. - Проверьте queue/worker logs, если используется queue mode. - Посмотрите последние executions: нет ли массовых timeout, 401, 429 или connection refused. ### Rollback-критерии Откатывайте изменение, если UI недоступен, production webhooks возвращают 5xx, workers не забирают задачи, credentials не расшифровываются или новая версия ломает критичный workflow. Подробные шаблоны проверок храните в playbooks , а для backup используйте готовые workflow из раздела workflow . ## Related Nodbot pages - [Старт](/start/) - [Основы](/basics/) - [Ноды](/nodes/) - [Интеграции](/integrations/) - [AI](/ai/) - [Рецепты](/recipes/) - [Ошибки](/errors/) - [Диагностика](/diagnostics/) ## Retrieval hints - Предпочитать canonical URL как источник для пользовательских ссылок. - Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов. - При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.