Обработка ошибок n8n начинается с отдельного сценария с Error Trigger. Вы выбираете его в настройках основного процесса, а при неуспешном автоматическом выполнении он отправляет уведомление. Проверяемый результат - сообщение, по которому ответственный понимает, какая автоматизация остановилась и где посмотреть запуск.
Уведомление само по себе не восстанавливает процесс. Если не создалась заявка в CRM, после сообщения ещё надо выяснить причину и результат записи. Здесь настроим именно сигнал о сбое и проверку его доставки, без перестройки всей интеграции.
Настройки сверены с официальной документацией двенадцатого октября две тысячи двадцать шестого года. Примеры учебные: они не описывают клиентский кейс и не означают, что проверка выполнена в вашей версии n8n. Если платформу ещё только выбираете, сначала прочитайте обзор n8n для бизнеса.
Где вы сейчас: нужен ли Error Trigger
- Процесс уже работает, но о сбое сообщает клиент. Начните с неуспешного выполнения в Executions и настройки отдельного обработчика.
- Error Trigger добавлен, а сообщений нет. Проверьте поле Error workflow основного процесса и способ запуска: ручная кнопка для этой проверки не подходит.
- Уведомление приходит, но из него непонятно, что делать. Добавьте название процесса, доступную ссылку на выполнение и ответственного; уберите клиентские данные.
- Сообщения есть, а исполнитель предлагает повторять каждый сбой. Сначала разделите повтор ноды и повтор внешней записи. Не запускайте создание сделки заново при неизвестном результате первой попытки.
Если остановилась сама нейросеть, выбор запасного поставщика решает другую задачу. Она разобрана в статье про запасной план на случай сбоя ИИ. Настройка Error Trigger помогает увидеть неуспешное выполнение, но не превращает недоступный сервис в рабочий.
Что подготовить до настройки
Делайте настройку вместе с человеком, который поддерживает вашу автоматизацию. Попросите его выделить отдельный тестовый процесс. В нём не должно быть создания настоящих сделок, отправки сообщений покупателям, списания денег и передачи клиентских данных в сторонние сервисы.
Не ограничивайтесь заменой последней ноды. Если раньше по пути уже отправляется письмо или создаётся задача, действие произойдёт до намеренной ошибки. Для проверки связи обработчика достаточно короткого отдельного сценария, который вообще не выполняет бизнес-операций.
Подготовьте доступ к двум спискам Executions: основного тестового процесса и будущего обработчика. Заранее выберите свой тестовый адрес или закрытый служебный канал. У человека, который принимает результат, должен быть доступ к полученному сообщению, а не только к экрану исполнителя.
Названия кнопок ниже взяты из текущей документации n8n. Если интерфейс вашей версии отличается, сопоставьте его с документацией и зафиксируйте версию. Не обновляйте рабочий сервер только ради совпадения с иллюстрацией чужой инструкции.
Обработка ошибок n8n: три разных механизма
Workflow - сценарий из связанных действий. Node, или нода, - одно действие внутри него. Execution - конкретный запуск сценария. Эти слова будут встречаться в настройках и журнале.
| Механизм | Что делает | Что им не подтверждено |
|---|---|---|
| Error Trigger в отдельном Error workflow | Получает сведения о неуспешном выполнении связанного процесса | Что ошибка исправлена и заявка дошла до CRM |
| Retry On Fail в Settings ноды | Повторяет запрос после ошибки | Что повтор внешней записи не создаст вторую карточку |
| On Error: Continue или Continue using error output | Позволяет продолжить выполнение, в том числе передать сведения об ошибке дальше | Что весь запуск получит статус Failed и вызовет Error workflow |
В документации настроек нод вариант Stop Workflow останавливает выполнение при ошибке. Continue разрешает следующий шаг, а Continue using error output передаёт сведения об ошибке для дальнейшей обработки.
Поэтому «нода показала ошибку» и «весь процесс завершился неуспешно» - разные события. Если ошибка обработана внутри сценария и выполнение не стало неуспешным, ожидать глобальное уведомление только от Error Trigger нельзя. У такой ветки должно быть своё согласованное действие: например, запись в список ручной проверки.
Для первого варианта выберите одну границу: критический шаг останавливает процесс, отдельный обработчик сообщает об остановке. Более сложные ветви добавляйте после проверки этой связи. Параллельно проверьте, где сохраняется само входное обращение: сигнал о сбое не заменяет его хранение.
Как связать процесс с обработчиком ошибок
Официальная инструкция по обработке ошибок разрешает использовать один обработчик для нескольких процессов. В первой проверке достаточно одной связи, чтобы результат было легко проследить.
Создайте отдельный сценарий с Error Trigger
Откройте новый workflow и добавьте Error Trigger первым шагом. Дайте ему понятное имя, например «Уведомление о сбое», и сохраните. Не смешивайте этот сценарий с переносом заявок: его задача - принять сведения об ошибке и уведомить ответственного.
Проверка шага: сохранённый обработчик начинается именно с Error Trigger. По документации отдельно публиковать workflow для работы этого триггера не требуется. Это отличается от автоматического тестового процесса, который позже надо включить для проверки.
Добавьте отправку короткого сообщения
После Error Trigger поставьте ноду того канала, который уже подключён и проверен у вас. Это может быть служебная почта или канал команды. Для почты в n8n есть Send Email, который использует SMTP-сервер. Настройте отправителя и только свой тестовый адрес, без клиентов в копии письма.
В сообщение включите название workflow, последнюю выполнявшуюся ноду, если она передана, и ссылку на выполнение, если она есть. Поля входа описаны в документации Error Trigger. Не пересылайте весь вход, сырой текст ошибки и stack: там могут оказаться сведения клиента или подробности запроса.
Проверка шага: выбран правильный получатель, у исполнителя есть подтверждение работоспособности канала. Реальную доставку уведомления именно от Error Trigger проверим автоматическим тестом. Наличие SMTP-подключения ещё не доказывает её.
Назначьте обработчик основному процессу
Откройте тестовый основной workflow. Перейдите в Options, затем Settings. В поле Error workflow выберите сохранённое «Уведомление о сбое» и сохраните настройки.
Проверка шага: снова откройте Settings и убедитесь, что выбран нужный обработчик. Если позже добавите второй рабочий процесс, назначение повторяется для него отдельно. Совпадение названия ноды не создаёт эту связь автоматически.
Проверьте остановку на критической ошибке
Откройте Settings того шага, который должен останавливать основной процесс. Для первого теста проверьте поведение On Error: Stop Workflow. Не включайте Continue только ради зелёного статуса: так вы меняете дальнейший путь данных.
Проверка шага: после критического сбоя нет перехода к записи в рабочую систему. В тестовом процессе записи вообще должны отсутствовать. Для реальной автоматизации исполнитель отдельно показывает, какая ветка вызывается при ошибке и где сохраняется необработанное событие.
Текст уведомления без клиентских данных
Ниже пример выражения для текстового поля ноды уведомления. Переключите поле в режим Expression; способ выбора поля зависит от выбранного канала. Это учебный шаблон по входным полям Error Trigger, а не готовое подключение почты.
{{ [
'Ошибка автоматизации',
'Сценарий: ' + ($json.workflow?.name ?? 'не указан'),
'Узел: ' + ($json.execution?.lastNodeExecuted ?? 'нет данных'),
'Запуск: ' + ($json.execution?.url ?? 'ссылка недоступна'),
'Действие: откройте журнал и проверьте результат до повтора'
].join('\n') }}Поля execution.url и execution.id зависят от сохранения выполнения в базе. При ошибке запускающей ноды основного процесса их нет; часть сведений приходит в trigger.error. Поэтому отсутствие ссылки должно давать понятную надпись, как в примере, а не новую ошибку самого обработчика.
Короткое сообщение сознательно не включает execution.error.message. Подробности смотрят в защищённом журнале. Если вам нужен код ошибки в уведомлении, заранее согласуйте безопасный список полей, а не пересылайте целиком ответ внешнего сервиса.
Как проверить уведомление на автоматическом запуске
В документации Error Trigger прямо указано: триггер работает, когда ошибкой заканчивается автоматическое выполнение. Поэтому проверка «нажал кнопку, увидел красную ноду» не завершает приёмку уведомления.
Попросите исполнителя собрать короткую тестовую копию: Schedule Trigger, который запускает процесс по выбранному расписанию, затем Stop And Error. Второй узел по документации позволяет намеренно завершить выполнение ошибкой. Введите в нём безопасный текст вроде «Учебный сбой для проверки уведомления», без имени клиента и номера реальной заявки.
Назначьте этой копии Error workflow из предыдущего раздела. Выберите в Schedule Trigger правило Trigger Rules и интервал Trigger Interval. Сверьте часовой пояс workflow: от него зависит время запуска. Согласуйте ближайшее тестовое выполнение, сохраните и опубликуйте только тестовый процесс, затем дождитесь его запуска по расписанию. Не запускайте рабочую заявку ради проверки. Включение тестового расписания и его последующее отключение должен контролировать ответственный за n8n.
| Где смотреть | Что ожидаем увидеть | Что означает отсутствие |
|---|---|---|
| Executions тестового процесса | Новое неуспешное выполнение после автоматического запуска | Сначала проверяем запуск расписания и путь до Stop And Error |
| Executions обработчика | Выполнение после этого сбоя, связанное с нужным workflow | Проверяем назначение Error workflow и режим основного запуска |
| Свой тестовый адрес или служебный канал | Сообщение с названием нужного процесса | Проверяем ноду доставки, получателя и журнал отправки |
Это таблица ожидаемых результатов. Заполните рядом фактические наблюдения своей копии: время, ссылку или идентификатор выполнения, статус обработчика и получение сообщения. Ничего из этой таблицы не считается уже выполненным только потому, что сценарий сохранён.
После проверки отключите временный автоматический запуск. Не оставляйте Schedule Trigger бесконечно создавать учебные ошибки. Сам обработчик можно сохранить для дальнейшего назначения, но включение рабочих процессов требует отдельной сверки их настроек и доступа к каналу.
Если у вас сценарий с ИИ, проверку качества ответа модели проводят дополнительно. Успешное сообщение об ошибке не подтверждает, что модель верно разобрала обращение. Для такой приёмки пригодится отдельный материал про тестирование ИИ-агентов.
Почему сообщение не пришло
| Симптом | Что проверить | Чего не делать |
|---|---|---|
| Ошибка видна только после ручного Execute | Был ли автоматический запуск основного процесса | Не считать ручной запуск тестом Error Trigger |
| Нода сообщила об ошибке, а запуск успешен | On Error и ветку продолжения после ошибки | Не ждать глобального уведомления за обработанную ошибку автоматически |
| Основной запуск Failed, обработчика нет | Назначение Error workflow в Settings нужного процесса | Не создавать второй обработчик до проверки связи |
| Обработчик запустился, сообщение не получено | Результат ноды доставки, адрес и доступ к каналу | Не считать зелёную ноду доказательством прочтения сообщения |
| Обработчик падает при чтении ссылки | Есть ли execution и execution.url в фактическом входе | Не требовать поле, которое отсутствует в этом виде ошибки |
| Не открывается сам n8n или не работает его сервер | Доступность инфраструктуры отдельным внешним наблюдением | Не ждать, что неработающий n8n надёжно сообщит сам о себе |
Отдельный Error workflow выполняется внутри той же системы. Из этого следует практическая граница: для остановки самого сервера нужен внешний контроль доступности. Внутренний обработчик нельзя принимать как гарантию уведомления о любой аварии.
Есть и более тихая проблема: расписание не запустилось вообще. В таком случае у вас нет обычного неуспешного выполнения, на которое вы рассчитывали. Для критичного процесса заранее задайте ожидаемый результат за период: например, отчёт должен появиться к согласованному времени. Отсутствие этого результата проверяйте отдельно от ошибок запусков, которые уже начались.
Когда повторять запрос после ошибки
В официальном разделе Handle rate limits Retry On Fail включает повтор ноды. Настройка находится в Settings. Wait Between Tries ms задаёт паузу между попытками; для ограничения частоты запросов её выбирают по правилам конкретного сервиса.
Не берите одно число попыток из чужой статьи для всех подключений. Ограничьте количество и паузу вместе с исполнителем, запишите выбранные значения и проверьте, что после исчерпания попыток запуск переходит в ожидаемое состояние. Если нужная пауза не укладывается в настройку ноды, разберите с ним отдельную логику ожидания.
При неверных правах повтор того же запроса обычно не исправит доступ. При пустом обязательном поле надо исправить вход. При сетевой ошибке во время создания сделки сначала выясните, появилась ли она в CRM: сообщение «запрос не завершён» не доказывает, что запись не произошла.
Порядок безопасного восстановления и различие между событием и карточкой разобраны в статье про дубли заявок в n8n. Здесь достаточно одного ограничения: не разрешайте обработчику автоматически повторять всю бизнес-цепочку, пока неизвестен результат её внешних действий.
Повтор сохранённого выполнения в Executions - ещё один отдельный механизм. Документация n8n предлагает Retry with currently saved workflow и Retry with original workflow. В первом случае используются сохранённый после правок сценарий и прежние данные выполнения, во втором - исходный сценарий и прежние данные. Выбор варианта не заменяет сверку уже совершённых действий.
Что попросить у исполнителя
Можно передать такое требование:
Настройте отдельный обработчик ошибок для указанного процесса n8n. Проверьте связь на безопасной автоматической копии без рабочих записей и клиентских данных. Покажите неуспешное выполнение, запуск обработчика и сообщение на нашем тестовом адресе. Отдельно укажите, что произойдёт при ошибке доставки и остановке самого n8n. Автоматический повтор записи в CRM без известного результата предыдущей попытки не включайте.
Для приёмки достаточно короткого листа. Название основного процесса, назначенный Error workflow, версия n8n, канал и ответственный. Рядом - фактический тестовый запуск, результат отправки и ограничения проверки. Поля с реальными паролями, токенами и данными клиента в этот лист не входят.
| Проверка | Факт, который заполняет исполнитель |
|---|---|
| Основной процесс связан с обработчиком | Названия обоих workflow и сохранённое назначение в Settings |
| Проверка была автоматической | Время и идентификатор тестового выполнения |
| Обработчик получил именно этот сбой | Идентификатор его выполнения и название основного workflow во входе |
| Уведомление получено | Подтверждение на согласованном адресе или в канале |
| Нет лишних внешних действий | Перечень нод тестовой копии и отсутствие рабочих записей |
| Временный тест остановлен | Отключённый автоматический запуск тестового процесса |
Такой лист помогает принять один конкретный результат. Он не подтверждает готовность всей автоматизации к любому отказу, защиту от параллельных записей и восстановление после потери сервера.
Если в существующей интеграции неясно, где хранится обращение и кто получает ошибку, подготовьте описание одного процесса для автоматизации бизнеса в ClaudeLab. Укажите исходный сервис, нужный результат и наблюдаемый сбой. Ключи доступа и выгрузки клиентов в первое описание не прикладывайте.
Чек-лист
- Назначение Error workflow сохранено в нужном основном процессе; обработчик начинается с Error Trigger.
- Проверка выполнена автоматически в отдельной копии без рабочих записей, клиентских сообщений и платежей.
- Неуспешное выполнение, запуск обработчика и фактически полученное уведомление сопоставлены между собой.
- Сообщение понятно ответственному, не пересылает клиентские данные и переносит отсутствие ссылки на выполнение.
- Повторы внешних операций не включены при неизвестном результате; граница внутреннего обработчика и внешнего контроля названа.
- Временный Schedule Trigger отключён после проверки, факты и ограничения сохранены в листе приёмки.
Источники
Названия настроек и ограничения сверены двенадцатого октября две тысячи двадцать шестого года. Первичные материалы подтверждают функции n8n; учебный маршрут не заменяет испытание вашей среды.
- Handle errors gracefully - привязка Error workflow и намеренная ошибка через Stop And Error.
- Error Trigger - автоматические выполнения, отсутствие отдельной публикации обработчика и поля ошибки.
- Work with nodes - On Error, Stop Workflow и продолжение выполнения.
- Handle rate limits - Retry On Fail и пауза между попытками.
- View executions for a single workflow - просмотр запусков и варианты повтора.
- Send Email - отправка через SMTP-сервер.
- Schedule Trigger - расписание, часовой пояс и публикация тестового процесса.
- Expressions for data transformation - режим выражений и доступ к входным данным.