Error Trigger в n8n: error workflow, алерты и разбор failed executions ¶
Обновлено: 2026-05-29
Error Trigger запускает отдельный workflow, когда связанный workflow падает с ошибкой. Это основа нормального мониторинга n8n: не ждать, пока менеджер заметит пропавшие заявки, а сразу получать понятный алерт с названием workflow, ошибкой, execution URL и краткой подсказкой, что проверить.
Важно
Error workflow не заменяет аккуратную обработку ошибок внутри основного workflow. Для ожидаемых ошибок API используйте retry, IF, fallback и логирование. Error Trigger нужен для failed executions, которые требуют внимания.
Минимальная схема error workflow ¶
- Создайте новый workflow.
- Поставьте Error Trigger первой нодой.
- Добавьте Edit Fields или Code node, чтобы собрать короткое сообщение.
- Отправьте алерт в Telegram, Slack, email или внутренний чат.
- В основном workflow откройте настройки и выберите этот error workflow.
- Сделайте тестовую ошибку на безопасном workflow и проверьте сообщение.
Что должно быть в алерте ¶
Плохой алерт: «n8n error». Хороший алерт помогает сразу понять, куда смотреть:
- название workflow;
- execution URL или ID;
- название ноды, где случилась ошибка;
- короткий текст ошибки;
- тип входного события: webhook, schedule, manual, queue;
- external_id заявки/платежа/события, если он есть;
- первое действие: проверить credentials, API status, payload, лимит или timeout.
n8n: ошибка workflow
Workflow: Tilda → Bitrix24
Node: Create lead
Error: 401 Unauthorized
External ID: tilda_1001
Что проверить: Bitrix24 webhook/token и права на создание лидаКогда ошибка должна падать, а когда нет ¶
| Ситуация | Лучшее поведение | Почему |
|---|---|---|
| API временно вернул 429 | retry + Wait, алерт после нескольких неудач | одиночный 429 не должен будить команду |
| credential истёк | failed execution + Error Trigger | нужно быстро восстановить доступ |
| необязательное поле отсутствует | обработать внутри workflow | это ожидаемый вариант данных |
| платёж пришёл с неизвестным статусом | лог + ручная проверка | лучше не менять CRM автоматически |
| Code node вернул некорректный JSON | failed execution + алерт | это ошибка логики workflow |
Stop and Error для контролируемых падений ¶
Иногда workflow должен упасть специально: например, подпись webhook не совпала, обязательный ID заказа пустой или CRM вернула невозможное состояние. Для таких случаев можно использовать Stop and Error. Это лучше, чем silently пропустить событие: error workflow получит сигнал, а в execution останется понятная причина.
Как не утонуть в алертах ¶
Error Trigger легко превратить в источник шума. Чтобы этого не случилось:
- группируйте однотипные ошибки по workflow и node;
- не отправляйте полный payload с персональными данными в чат;
- добавьте severity: warning, error, critical;
- для массовых ошибок отправляйте дайджест, а не 100 сообщений подряд;
- храните таблицу инцидентов с first_seen, last_seen и count.
Защита от циклов ¶
Сам error workflow тоже может упасть: Telegram credential истёк, Slack API недоступен, Code node сломался. Не делайте error workflow слишком сложным. Он должен быть короче основного процесса и иметь минимум внешних зависимостей. Если нужно логирование в базу и уведомление в чат, сначала пишите в базу, потом отправляйте сообщение.
Что проверять при failed execution ¶
| Шаг | Что смотреть | Типичная причина |
|---|---|---|
| 1 | нода, где остановился workflow | ошибка API, mapping, JSON или credential |
| 2 | input/output этой ноды | неожиданный payload или пустое поле |
| 3 | статус HTTP | 401, 403, 404, 429, 500 |
| 4 | последние изменения workflow | сломанный mapping после правки |
| 5 | повторный запуск на тестовом payload | постоянная или временная ошибка |
Практический контекст для внедрения ¶
Эта страница полезна не как абстрактная справка, а как рабочая инструкция под использование ноды/паттерна «Error Trigger в n8n: error workflow, алерты и разбор failed executions» в рабочем workflow, где важно понимать входные items и формат результата. Перед изменением workflow зафиксируйте источник события: входные данные по теме error trigger: webhook, schedule, ручной запуск или событие внешнего сервиса. Так проще отделить ошибку данных от ошибки настройки n8n и не превратить исправление в набор случайных правок.
Минимальная проверка перед публикацией workflow: один happy path, один пустой payload, один повтор события и одна ошибка внешнего сервиса. Для мониторинга используйте successful executions, skipped items, retry count, error branch usage; эти показатели быстро покажут, что сценарий работает иначе, чем ожидалось.
Связанные материалы ¶
- Обработка ошибок в n8n — общий подход к ошибкам.
- Error workflow → Telegram alert — готовый шаблон.
- HTTP Request — статусы, retry и timeout.
- Incident response — порядок действий при инциденте.