Инцидент: 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. |
| Ключевые понятия |
|
| 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 и отсутствие роста очереди.
Связанные материалы ¶
Практический минимум перед закрытием задачи ¶
- назначьте владельца 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.