Инцидент: webhooks n8n не работают ¶

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

Инцидент “webhooks down” означает, что внешние события не попадают в n8n или возвращают неправильный HTTP-ответ. Это не то же самое, что stuck workers или slow database: workflow может быть активен, воркеры свободны, но запрос ломается на DNS, TLS, reverse proxy, HTTP method, path conflict или неправильном production URL. Runbook должен быстро отделить сетевой слой от проблемы в самом workflow.

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

Если webhooks n8n не работают, сначала проверьте active workflow и правильный production webhook URL, затем DNS/TLS/reverse proxy, HTTP method/path, логи n8n и ответ curl снаружи. 404 часто указывает на inactive workflow или неверный path, 405 — на неверный method, 502/504 — на proxy/upstream, а пустой execution при успешном HTTP — на routing до n8n без запуска нужного workflow.

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

Эта страница про входной HTTP-трафик. Она не про очередь worker jobs и не про Postgres performance; главный диагностический объект — внешний запрос до webhook endpoint и его путь через proxy к n8n.

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

форма, платёжная система или CRM перестали доставлять события в n8n
curl на webhook возвращает 404, 405, 502, 504 или пустой ответ
после деплоя изменился домен, WEBHOOK_URL или reverse proxy
часть webhooks работает, а конкретный path или method нет

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

Зафиксируйте симптом: статус-код, URL, method, время, source system и trace/request id.
Проверьте, что workflow active и используется production URL, а не test webhook URL.
Снаружи выполните curl с тем же method, headers и минимальным payload.
Проверьте DNS, TLS certificate, reverse proxy route, body size и upstream timeout.
Сравните path и method с Webhook node; исключите path conflict с другим workflow.
Откройте n8n logs и execution history: появился ли execution при входящем запросе.

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

тестируют test URL вместо production URL и делают неверный вывод
смотрят только n8n UI, не проверяя DNS/TLS/proxy снаружи
игнорируют method: сервис шлёт GET, а Webhook node ждёт POST
обновили WEBHOOK_URL, но не перезапустили контейнер или не обновили proxy
не фиксируют raw статус-код, поэтому инцидент превращается в “не работает”

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

Внешний curl до production URL создаёт execution в нужном workflow.
Webhook отвечает ожидаемым статусом и телом ответа.
Источник события снова доставляет callback без retry storm.
В incident log записаны root cause, статус-код, исправление и smoke-test.

Слои диагностики webhook-инцидента ¶

Двигайтесь сверху вниз: source system → DNS/TLS → reverse proxy → n8n webhook endpoint → workflow execution. Если execution не появляется, проблема почти всегда до бизнес-логики. Если execution появляется, но результат неверный, переключайтесь на диагностику конкретной ноды, credentials или payload validation. Такое разделение убирает каннибализацию с runbook про stuck workers.

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

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

n8n webhook
production webhook URL
DNS
TLS certificate
reverse proxy
HTTP method
path conflict
curl smoke-test

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

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

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

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

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

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

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

FAQ ¶

Почему webhook отдаёт 404? ¶

Частые причины: workflow inactive, используется test URL, неверный path или конфликт route после изменения домена.

Почему webhook отдаёт 405? ¶

Обычно source system отправляет не тот HTTP method, который настроен в Webhook node.

Что проверить после исправления? ¶

Внешний curl, execution history, ответ source system и отсутствие повторных callback retry.

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

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