Обработка ошибок в n8n: error workflow и уведомления об ошибках

Error workflow — это в n8n совершенно обычная автоматизация, которую вы задаёте в настройках workflow в поле "Error workflow" и которая запускается автоматически, как только выполнение другого workflow завершается ошибкой. В сочетании с узлом Error Trigger, настройками Retry On Fail отдельных узлов и уведомлением по электронной почте или через Microsoft Teams это позволяет гарантировать, что ошибки не остаются незамеченными, а автоматически повторяются или сообщаются ответственной команде. По состоянию на: июль 2026.

Что такое error workflow и когда он срабатывает?

Согласно документации n8n, error workflow — это отдельный workflow, который вы задаёте "в Workflow Settings" для другой автоматизации и который выполняется, как только её выполнение завершается ошибкой. Типичный сценарий использования, согласно документации, — отправка "уведомлений по электронной почте или в Slack" при возникновении ошибки. Один error workflow можно повторно использовать для нескольких рабочих workflow, поэтому не нужно создавать отдельную обработку ошибок для каждой автоматизации. Важно, что error workflow нельзя протестировать вручным запуском: согласно документации, Error Trigger реагирует исключительно тогда, когда автоматизированное выполнение другого workflow действительно завершается ошибкой. Подробнее об этом можно узнать в документации n8n по обработке ошибок.

Как настроить error workflow?

Сначала вы создаёте отдельный workflow, который существует исключительно для случая ошибки, а затем связываете его с отслеживаемым workflow.

• Создать workflow обработчика ошибок: Создайте новый workflow с узлом Error Trigger в качестве первого узла, дайте ему имя, например "Error Handler", и сохраните его.
• Открыть целевой workflow: Откройте workflow, ошибки которого вы хотите отслеживать, и перейдите там в Options, а затем в Settings.
• Назначить error workflow: В поле "Error workflow" выберите ранее созданный workflow обработчика ошибок и сохраните настройку.

Workflow, который запускается только через Error Trigger, не нужно публиковать отдельно, чтобы он работал как error workflow.

Какую информацию предоставляет Error Trigger при ошибке?

Error Trigger передаёт структурированные данные о завершившемся ошибкой выполнении, на основе которых можно составить содержательное уведомление. Согласно документации по узлу Error Trigger эти данные включают, среди прочего:

• execution.id и execution.url: идентификатор и ссылка на завершившееся ошибкой выполнение, однако отсутствуют, если ошибка возникает уже в запускающем триггерном узле основной автоматизации.
• execution.error: собственно сообщение об ошибке, включая трассировку стека (stack trace).
• execution.lastNodeExecuted: узел, на котором выполнение завершилось ошибкой.
• execution.retryOf: присутствует только в том случае, если завершившееся ошибкой выполнение само уже было повтором.
• workflow.id и workflow.name: какой workflow затронут.

Кроме того, с помощью узла Stop And Error можно намеренно вызвать ошибку, например, чтобы целенаправленно запустить error workflow при неправдоподобных данных, даже если технически ошибки узла нет.

Как автоматически повторить неудавшийся вызов с помощью Retry?

Прежде чем выполнение вообще будет считаться окончательно завершившимся ошибкой и попадёт в error workflow, каждый отдельный узел можно настроить так, чтобы он сначала автоматически повторял неудавшийся вызов несколько раз. Для этого откройте соответствующий узел, перейдите в настройки и включите там "Retry On Fail". С помощью "Max Tries" вы задаёте, сколько раз n8n повторяет попытку, с помощью "Wait Between Tries (ms)" — время ожидания между попытками в миллисекундах. Оба значения ограничены согласно документации по работе с ограничениями скорости (rate limits) API: Max Tries — максимум 5, Wait Between Tries — максимум 5000 миллисекунд. Особенно для сервисов с ограничениями скорости документация рекомендует устанавливать время ожидания выше интервала ограничения скорости соответствующего API, чтобы следующая попытка не была снова отклонена.

Как уведомить свою команду по электронной почте или через Microsoft Teams?

После Error Trigger просто добавьте в error workflow узел, через который должно отправляться уведомление. Для уведомлений по электронной почте подходит узел Send Email, для которого требуется подключение с учётными данными SMTP и который отправляет сообщения в виде текста, HTML или в обоих форматах. Для сообщения в канал Teams доступен узел Microsoft Teams, который публикует сообщения в канал с использованием сохранённых учётных данных Microsoft. В обоих случаях текст сообщения формируется из полей, предоставляемых Error Trigger, например имени workflow, сообщения об ошибке из execution.error и ссылки на выполнение через execution.url, чтобы получатели сразу видели, какой процесс затронут и где можно посмотреть подробности. Тем, кто хочет технически грамотно защитить существующую среду n8n с помощью error workflow, стратегий Retry и уведомлений, окажут поддержку услуги n8n от NordFlux.

Часто задаваемые вопросы об обработке ошибок в n8n

Нужен ли отдельный error workflow для каждого workflow?

Нет, один error workflow можно задать в настройках нескольких workflow в качестве общего error workflow. Таким образом, для многих рабочих workflow часто достаточно одной централизованной автоматизации уведомлений. Для особенно критичных процессов вы всё же можете создать специализированный error workflow с собственной логикой эскалации.

Можно ли протестировать error workflow вручную?

Нет, согласно документации n8n, error workflow нельзя протестировать вручным запуском, так как Error Trigger реагирует только тогда, когда автоматизированное выполнение другого workflow действительно завершается ошибкой. Чтобы всё же проверить это поведение, вы можете в тестовом workflow с помощью узла Stop And Error намеренно вызвать ошибку и тем самым запустить связанный error workflow.

В чём разница между Retry On Fail и error workflow?

Retry On Fail автоматически повторяет вызов отдельного узла в рамках того же выполнения, тогда как error workflow срабатывает только тогда, когда всё выполнение окончательно завершилось ошибкой несмотря на все попытки повтора. Оба механизма разумно дополняют друг друга: retry устраняют кратковременные сбои, такие как превышение ограничений скорости, а error workflow затем информирует людей об окончательных сбоях.

Должен ли workflow обработчика ошибок быть активирован или опубликован?

Нет, workflow, который запускается исключительно через Error Trigger, согласно документации не нужно публиковать отдельно, чтобы он работал. Он вызывается автоматически, как только другой workflow ссылается на него в своих настройках как на error workflow и сам завершается ошибкой.