Error workflow в n8n: runbook для алертов и triage ¶

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

Intent: runbook error workflow: Error Trigger, alerting, triage, контекст ошибки, Stop and Error, защита от рекурсивных уведомлений
H1: Error workflow в n8n: как настроить алерты, triage и безопасную обработку ошибок
Schema: TechArticle, HowTo, FAQPage, BreadcrumbList
Old word count: 660
New word count: 788

Короткий ответ ¶

Error workflow в n8n должен не просто отправлять сообщение “workflow упал”, а давать triage-контекст: workflow name, execution ID, node, error message, external event ID, severity и ссылку на инструкцию. Начинайте с отдельного workflow с Error Trigger, подключайте его в настройках production-workflow и не забывайте защиту от рекурсивных уведомлений. Error workflow не заменяет retry, DLQ и журнал событий — он только быстро сообщает, что пошло не так.

Когда нужен этот runbook ¶

Страница подходит, если ошибки workflow обнаруживаются слишком поздно: клиент уже написал, заказ не ушёл в CRM, платеж не сверился, бот молчит, а в n8n failed execution лежит без уведомления.

Симптомы:

• failed executions есть, но никто их не смотрит;
• Slack/Telegram получает слишком мало или слишком много алертов;
• сообщения об ошибке не содержат payload ID;
• on-call не понимает, что делать после алерта;
• error workflow сам падает и создаёт шум;
• разные workflow отправляют ошибки в разных форматах.

Цель — сделать единый аварийный формат, по которому человек за 1–2 минуты понимает масштаб и первый шаг.

1. Что должно быть в алерте ¶

Плохой алерт: “n8n error”. Хороший алерт отвечает на вопросы: где, что, насколько критично и что делать дальше.

Минимальные поля:

Для платежей, CRM и поддержки добавьте бизнес-поля: order_id, lead_id, customer_id, ticket_id, payment_id.

2. Базовая схема error workflow ¶

Практичный error workflow состоит из пяти зон:

1. Error Trigger — принимает событие ошибки.
2. Normalize — приводит поля к единому формату.
3. Classify — определяет severity и тип: auth, rate limit, provider down, validation, bug.
4. Notify — отправляет в Slack/Telegram/email/incident tool.
5. Journal — пишет запись в таблицу или базу для дальнейшего replay/аналитики.

Если alerting и journal идут в одну внешнюю систему, всё равно разделяйте payload: сообщение для человека должно быть коротким, журнал — полным и машинно-читаемым.

3. Классификация severity ¶

Не все ошибки одинаковы. Без классификации команда быстро перестаёт читать алерты.

Пример правил:

Severity можно определять по workflow tag, имени workflow, node, HTTP status, количеству ошибок за окно времени и типу бизнес-события.

4. Защита от шума и рекурсии ¶

Error workflow тоже может упасть: Telegram credential истёк, Slack API дал 429, таблица журнала недоступна. Поэтому ему нужна собственная устойчивость.

Что добавить:

• fallback-канал уведомления;
• ограничение частоты сообщений;
• группировку одинаковых ошибок;
• защиту от self-error loops;
• короткий timeout для внешних уведомлений;
• запись локального минимального лога, если внешний журнал недоступен.

Не отправляйте полный payload с персональными данными в общий чат. Лучше отправить ID и ссылку на execution, а чувствительные поля оставить в защищённом журнале.

5. Как подключать к production workflow ¶

Процесс внедрения:

1. Создать единый Error Handler workflow.
2. Добавить Error Trigger первым node.
3. Настроить normalizer и message template.
4. Подключить error workflow в настройках целевого workflow.
5. Вызвать controlled error через Stop and Error или тестовый endpoint.
6. Проверить, что alert содержит execution ID и runbook.
7. Зафиксировать владельца процесса.

Важно: ручные тесты и production-triggered executions могут вести себя по-разному. Проверяйте именно тот сценарий, который будет работать в active workflow.

6. Шаблон сообщения ¶

[n8n][S2] CRM lead sync failed
Workflow: Lead webhook → CRM
Execution: 123456
Node: Create/Update lead
Error: 429 Too Many Requests
External ID: lead_98765
Environment: production
First action: open runbook /playbooks/runbook-rate-limit/
Owner: marketing-ops

Такой формат можно быстро читать в чате, группировать и искать в истории.

7. Что делать после алерта ¶

• Открыть execution и проверить node/error.
• Определить, единичная ошибка или серия.
• Остановить источник лавины, если ошибок много.
• Проверить внешний provider status.
• Решить, нужен ли replay.
• Записать root cause и follow-up.

Error workflow должен помогать triage, а не превращаться в отдельный поток шума.

FAQ ¶

Нужно ли делать отдельный error workflow для каждого процесса?
Обычно лучше один общий error handler с классификацией, а для критичных процессов — дополнительные правила и владельцы.

Можно ли тестировать error workflow вручную?
Проверять логику можно controlled error, но важно учитывать, что Error Trigger предназначен для ошибок active workflow. Финальный тест делайте на сценарии, похожем на production.

Что отправлять в чат, если payload содержит персональные данные?
Не отправляйте полный payload. Дайте execution ID, business ID, тип ошибки и ссылку на runbook.

Что делать, если сам error workflow падает?
Нужен fallback: альтернативный канал, rate limit уведомлений и отдельный минимальный log.

{
  "source": "manual|webhook|schedule|api",
  "external_id": "stable-id-from-source",
  "received_at": "2026-05-29T10:00:00Z",
  "payload_version": "v1",
  "dry_run": true,
  "audit": {"workflow_id": "...", "execution_id": "..."}
}