Створи робочий процес обробки помилок в n8n і під'єднай його до продакшн-процесу
Покроковий туторіал: як створити error workflow в n8n з вузлом Error Trigger, під'єднати його в налаштуваннях, протестувати та виправити відсутні поля.
Перевірено за наведеними джерелами .
Мета і що потрібно підготувати
Мета цього туторіалу — один спільний робочий процес сповіщень: коли продакшн-автоматизація падає, error workflow в n8n запускається автоматично і повідомляє команді, що саме зламалося. Ти створюєш його один раз і під'єднуєш до кожного процесу, який тобі важливий.
Точкою входу для цього є вузол Error Trigger. Коли пов'язаний робочий процес падає, Error Trigger отримує деталі збою і запускає твій error workflow. Документація n8n прямо каже, що error workflow має починатися саме з цього вузла і що той самий error workflow можна перевикористовувати для багатьох процесів.
Перед стартом підготуй три речі: інстанс n8n, який ти можеш редагувати, збережений робочий процес, що запускається автоматично і який ти хочеш захистити, та канал сповіщень із робочими креденшелами — наприклад, вузол чату чи email.
Sources: Error Trigger | Nodes | n8n Docs, Handle errors gracefully | Build | n8n Docs
Створення і під'єднання error workflow, крок за кроком
Чотири кроки ведуть від порожнього полотна до перевірених сповіщень. Нумерований список нижче — ядро цього туторіалу; абзаци після нього пояснюють деталі, на яких люди спотикаються.
- Створи новий робочий процес, додай Error Trigger першим вузлом і збережи з чіткою назвою, наприклад Error Handler.
- Додай після тригера свій вузол сповіщень і змапь поля помилки в текст повідомлення.
- Відкрий продакшн-процес, перейди в Options, далі Settings, обери свій Error Handler у полі Error workflow і збережи.
- Додай вузол Stop And Error в одну з гілок продакшн-процесу, дай йому запуститися автоматично і переконайся, що сповіщення прийшло.
На другому кроці зроби мапінг даних, які дає тобі Error Trigger. Документований приклад payload містить execution id та url, повідомлення про помилку і stack, lastNodeExecuted, режим виконання, а також workflow id і name. Як редакційна порада: винеси назву робочого процесу, його id та lastNodeExecuted у перший рядок сповіщення, щоб черговий міг зорієнтуватися ще до відкриття n8n.
Третій крок — саме під'єднання. У процесі, який хочеш захистити, обери Options, далі Settings, потім вкажи свій error workflow у налаштуванні Error workflow і збережи. У документації з налаштувань робочого процесу це описано як вибір процесу, який запускається, якщо поточний процес падає. Документація n8n не наводить номерів версій для цих сторінок, тож формулювання меню може відрізнятися у твоїй редакції.
Четвертий крок — перевірка. Вузол Stop And Error примусово завалює виконання за обраних тобою умов і запускає error workflow, що є чистим способом перевірити зв'язку, не чекаючи реальної аварії.
Sources: Error Trigger | Nodes | n8n Docs, Handle errors gracefully | Build | n8n Docs, Configure workflow settings | Build | n8n Docs
Очікуваний результат і як його читати
Після невдалого автоматичного виконання твій error workflow в n8n запускається самостійно і сповіщення приходить. Відкрий Executions, щоб підтвердити: можна переглядати виконання для окремого процесу або для всіх процесів, до яких у тебе є доступ, а також увімкнути стрімінг логів.
Не кожне поле присутнє завжди — і це задокументована поведінка, а не баг. Execution id та url вимагають, щоб виконання було збережене в базі даних, і вони відсутні, коли помилка сталася в самому тригер-вузлі основного процесу. Поле retryOf з'являється лише для повторних виконань.
Таблиця нижче підсумовує, чого очікувати від кожної частини payload, коли проєктуєш текст сповіщення.
| Поле | Що воно каже | Коли може бути відсутнім |
|---|---|---|
| execution.id | Який запуск впав | Виконання не збережене в базі даних |
| execution.url | Пряме посилання на запуск | Помилка в тригер-вузлі основного процесу |
| execution.error | Повідомлення і stack | Невідомо |
| execution.lastNodeExecuted | Де саме зупинилося | Невідомо |
| execution.retryOf | Оригінальний запуск, який повторили | Присутнє лише для повторів |
| workflow.id і name | Яка автоматизація зламалася | Невідомо |
Sources: Error Trigger | Nodes | n8n Docs, Handle errors gracefully | Build | n8n Docs
Що робити, коли error workflow в n8n мовчить
Найпоширеніша несподіванка — тиша під час тестування. Документація зазначає, що error workflow не можна перевірити, запустивши процес вручну: Error Trigger спрацьовує, коли падає автоматичне виконання. Дай розкладу, вебхуку чи іншому тригеру зробити свою справу замість натискання Execute.
Якщо сповіщення приходять, але посилання на виконання не відкривається, перевір налаштування зберігання в тому ж вікні налаштувань — вони визначають, чи зберігаються невдалі виконання опублікованих процесів. У self-hosted n8n дані виконань також видаляє інстанс-рівневий pruning після налаштовуваного віку, із задокументованим значенням за замовчуванням 336 годин.
Від збою до сповіщення, з яким можна працювати
- Автоматичний запуск падає: Виконання за розкладом або за вебхуком завершується помилкою на вузлі.
- Спрацьовує Error Trigger: Пов'язаний error workflow стартує і отримує деталі збою.
- Формується повідомлення: Назва процесу, id та останній виконаний вузол потрапляють у текст сповіщення.
- Команда отримує сповіщення: Вузол сповіщень доставляє повідомлення в обраний канал.
- Виконання переглянуто: Хтось відкриває Executions, щоб дослідити невдалий запуск.
Також виріши, які саме збої взагалі варті уваги людини. Документація вузла HTTP Request описує ввімкнення Retry on Fail із Max Tries і Wait Between Tries у мілісекундах, що корисно проти відповідей із rate-limit; тимчасові збої тоді відновлюються самі, нікого не турбуючи.
Старіший розбір у блозі n8n від Tanay Pant, опублікований у 2020 році й зібраний на n8n 0.111.0, поєднує Error Trigger із вузлами сповіщень та навмисно зламаним другим процесом. Назви вузлів та інтерфейс відтоді змінилися, тож сприймай ту статтю як ілюстративний патерн, а не як актуальні кроки.
Sources: Error Trigger | Nodes | n8n Docs, Configure workflow settings | Build | n8n Docs, Executions | Deploy | n8n Docs, Common Issues | Nodes | n8n Docs, Creating error workflows in n8n – n8n Blog
Командні практики та best practices n8n щодо обробки помилок
Коли патерн працює, зроби з нього домовленість, а не особисту звичку. Оскільки один error workflow в n8n може обслуговувати багато процесів, домовтеся командою, що кожна автоматизація, яку виводять у продакшн, отримує спільний Error Handler ще до ввімкнення, і додайте цей пункт у чекліст рев'ю.
Ця єдина домовленість і є ядром best practices n8n щодо обробки збоїв: один власний обробник, свідомо під'єднаний і перевірений до запуску. Документація n8n не вимірює, наскільки швидше команди розв'язують інциденти після цього, тож сприймай вигоду як операційну ясність, а не як доведену метрику.
Sources: Handle errors gracefully | Build | n8n Docs
