Workflow упал, а вы узнали об этом случайно? Настроим Error Trigger: отдельную схему, которая после технического сбоя записывает событие в таблицу n8n. Проверим её настоящим POST-запросом к опубликованному Webhook, затем сравним ошибку, успешный запрос и ручной запуск. В конце отключим учебную точку входа.
Результат инструкции
Получатся две схемы: ezGPT - Error Demo намеренно завершает production-выполнение с ошибкой, а ezGPT - Error Log записывает её в ezgpt_error_log. Каждая запись содержит ID выполнения и workflow, название схемы, сбойный узел, короткий код, режим запуска и время регистрации. По ID вы найдёте подробности в Executions.
Это небольшой журнал технических ошибок, а не автоматическое исправление. AI, API-ключи, платные запросы и отправка уведомлений не нужны. Обработчик не превращает исходную ошибку в успех и не повторяет оплату или сообщение клиенту. Данные с needs_review, которые workflow успешно сохранил, сами по себе Error Trigger не запускают.
Что понадобится
- n8n с Data tables и правом создавать workflows в своём проекте. Пример проверен на версии 2.42.4.
- Доступ к настройкам Error workflow и публикации учебных схем. Оба workflow и таблицу создавайте в одном проекте.
- PowerShell на Windows или другой HTTP-клиент для POST. Пример команды использует локальный n8n на localhost:5679.
- Отдельная учебная таблица, без настоящих документов, клиентов и секретов. Для локальной установки нужен сохраняемый том n8n.
Установить локальный n8n через Docker
Шаг 1. Создайте таблицу журнала
Откройте свой проект → Data tables → Create Data table. Создайте таблицу From scratch с именем ezgpt_error_log. Если такая таблица уже есть, сначала выясните, кому она принадлежит; не очищайте чужой журнал ради теста. Для повторения инструкции нужна новая пустая учебная таблица.
Data tables не отображается? Проверьте версию и доступ у администратора. Не заменяйте таблицу закреплённым OUTPUT: после нового выполнения другой workflow должен читать сохранённые строки, а не прежний экран узла.
Шаг 2. Добавьте семь текстовых колонок
Добавьте колонки из таблицы. У всех тип string — текст. Имена копируйте точно: без пробелов, перевода и изменения регистра. Системные id, createdAt и updatedAt создаёт n8n, добавлять их вручную не нужно.
| Колонка | Тип | Что хранит |
|---|---|---|
| execution_id | string | ID сбойного выполнения |
| workflow_id | string | ID исходной схемы |
| workflow_name | string | Её название |
| failed_node | string | Узел, на котором произошёл сбой |
| error_code | string | demo_failed или workflow_failed |
| execution_mode | string | Режим исходного запуска |
| recorded_at | string | Время записи, ISO 8601 UTC |
recorded_at — момент подготовки записи обработчиком, не точное время начала сбоя. execution_id и workflow_id — разные идентификаторы; системный id относится к строке таблицы. При некоторых ошибках триггера execution_id отсутствует, поэтому код допускает пустой текст.
Шаг 3. Импортируйте обработчик
Скачать n8n-error-trigger-handler.json
Создайте новый workflow в этом же проекте. В меню редактора выберите Import from File и загрузите JSON. Если браузер открыл файл как текст, сначала сохраните его через «Сохранить как». Название — ezGPT - Error Log. На полотне должны быть три узла:
Error Trigger → Prepare Error → Save Error
При ручной сборке добавьте Error Trigger, Code и Data table, соедините последовательно и задайте такие же имена. Error Trigger ничего не опрашивает по расписанию: событие передаст n8n, когда связанная схема завершится с технической ошибкой.
Шаг 4. Подготовьте безопасный состав строки
Откройте Prepare Error: Language JavaScript, Mode Run Once for All Items. В импортированном файле уже есть код ниже. Он берёт семь нужных полей, не копируя тело запроса, stack и полный error.message в таблицу.
const text = value => value == null ? '' : String(value);
return $input.all().map((item, index) => {
const event = item.json;
const execution = event.execution ?? {};
const trigger = event.trigger ?? {};
const error = execution.error ?? trigger.error ?? {};
return {
json: {
execution_id: text(execution.id),
workflow_id: text(event.workflow?.id),
workflow_name: text(event.workflow?.name),
failed_node: text(execution.lastNodeExecuted ?? error.node?.name),
error_code: error.message === 'DEMO_TECHNICAL_FAILURE'
? 'demo_failed' : 'workflow_failed',
execution_mode: text(execution.mode ?? trigger.mode),
recorded_at: new Date().toISOString(),
},
pairedItem: { item: index },
};
});
demo_failed — наша учебная метка для сообщения DEMO_TECHNICAL_FAILURE. Остальные сообщения получают общий workflow_failed: это не классификатор причин и не AI-анализ. execution_mode сохраняет режим исходной схемы, например webhook, хотя сам обработчик выполняется в режиме error.
Обработка trigger.error предусмотрена на случай события без execution.id. Это не означает, что Error Trigger обнаружит любые аварии. Остановка сервера, потеря диска или падение процесса могут помешать запуску обработчика. Для таких событий нужен отдельный контроль доступности.
Шаг 5. Настройте Insert в журнал
Откройте Save Error. Resource: Row, Operation: Insert. Data table: By Name, значение ezgpt_error_log; можно выбрать ту же таблицу From list. Mapping Column Mode: Map Automatically. Выход Prepare Error и семь колонок должны совпадать по именам.
В Settings оставьте On Error: Stop Workflow. Не включайте Continue On Fail и автоматические повторы в этой учебной версии. Если таблица недоступна, запись не считается выполненной. Insert добавляет события, в отличие от Upsert последнего состояния заказа.
Чем Insert отличается от Upsert и как читать таблицу
Повторный отдельный POST создаёт новое исходное выполнение и новую строку. Журнал не гарантирует отсутствие дубликатов при повторной доставке одного события и не является неизменяемым аудитом: строки могут редактировать участники с соответствующими правами.
Шаг 6. Сохраните и опубликуйте обработчик
Сохраните ezGPT - Error Log и нажмите Publish. В проверенной версии n8n 2.42.4 неопубликованный обработчик не выполнялся: основной workflow падал, таблица оставалась пустой, а журнал n8n сообщал, что Error Workflow не активен. Поэтому здесь публикуем обе схемы, а не только сохраняем их.
В некоторых версиях n8n инструкция Error Trigger допускает работу без публикации. Для повторения нашего теста ориентируйтесь на проверенную версию и факт новой записи, а не только на наличие Error Trigger. После изменения узлов снова публикуйте актуальную версию.
В настройках обработчика не назначайте другой Error workflow и не стройте взаимную цепочку обработчиков. Если есть настройка разрешённых вызывающих workflows, разрешите исходную учебную схему из того же проекта, не открывая вызов всем проектам. В нашем тесте две схемы одного владельца работали с настройками вызова по умолчанию.
Шаг 7. Импортируйте исходную учебную схему
Скачать n8n-error-trigger-demo.json
Создайте второй новый workflow в том же проекте и импортируйте файл. Его название — ezGPT - Error Demo. Здесь Demo Webhook и Manual Trigger подключены к одному узлу Demo Failure. Первый нужен для настоящего POST, второй — только для сравнения ручного запуска.
Demo Webhook → Demo Failure
Manual Trigger → Demo Failure
Откройте меню схемы → Settings. В Error workflow выберите ezGPT - Error Log и сохраните настройки. В JSON нет ID вашего обработчика: эту связь нужно задать после импорта. Название файла не заменяет настройку Error workflow.
Шаг 8. Проверьте намеренную ошибку
В Demo Failure, узле Stop And Error, выберите Error Type: Error Message. В Error Message должен быть ровно текст ниже, без кавычек и Expression:
DEMO_TECHNICAL_FAILURE
В Settings этого узла оставьте On Error: Stop Workflow. Не выбирайте Continue: продолженная ошибка может не завершить workflow с ошибкой, и этот обработчик не получит ожидаемое событие. Узел должен быть включён.
Это учебная техническая ошибка, не повреждение сервера. Мы намеренно останавливаем свою схему, чтобы увидеть путь события. В настоящем workflow вместо Demo Failure будут HTTP Request, Code или другие узлы с реальными причинами сбоя.
Шаг 9. Опубликуйте Webhook и возьмите Production URL
В Demo Webhook проверьте HTTP Method: POST, Path: ezgpt-error-demo, Respond: Immediately. Затем сохраните и опубликуйте ezGPT - Error Demo. Дождитесь подтверждения публикации. В Webhook переключитесь на Production URL и скопируйте полный адрес.
Для локальной установки из нашей инструкции он обычно выглядит как http://localhost:5679/webhook/ezgpt-error-demo. Если ваш экземпляр показывает другой домен или порт, используйте свой адрес. Здесь нужен /webhook/, а не /webhook-test/. Нажимать Listen for test event для production-запроса не нужно.
Учебный Webhook без аутентификации используйте только на локальном экземпляре, доступном этому компьютеру. Не публикуйте его в интернете без контроля доступа. Метод POST и необычный путь не являются защитой. Для Cloud или сервера сначала настройте авторизацию и согласуйте тест с администратором.
Шаг 10. Отправьте первый POST
Откройте PowerShell на том же компьютере. В первой строке замените адрес на скопированный Production URL. Передаём только вымышленную метку; настоящие клиентские данные не нужны.
$url = 'http://localhost:5679/webhook/ezgpt-error-demo'
Invoke-RestMethod -Method Post -Uri $url `
-ContentType 'application/json' `
-Body '{"test":"ezgpt-demo"}'
Webhook отвечает сразу. HTTP 200 или ответ о старте означает приём запроса, не успех всей схемы: следующий узел специально завершит её с ошибкой. Откройте Executions исходного workflow и найдите новое выполнение со статусом Error и режимом webhook. Сбойный узел — Demo Failure.
В Executions обработчика должно появиться отдельное успешное выполнение с режимом error. Если его нет, проверьте связь Error workflow, публикацию обработчика и разрешение вызова. Новый execution ID отличается от прежних тестов; не оценивайте результат по закреплённым данным редактора.
Шаг 11. Сверьте первую запись и повторите запрос
Откройте ezgpt_error_log в Data tables и обновите список строк. Должна появиться одна запись. Сверьте execution_id с ID упавшего исходного выполнения, а не успешного обработчика. workflow_id и workflow_name относятся к ezGPT - Error Demo.
- failed_node: Demo Failure.
- error_code: demo_failed.
- execution_mode: webhook.
- recorded_at: дата и время ISO 8601 с Z на конце.
- Тело POST и полный текст ошибки отсутствуют среди семи пользовательских колонок.
Повторно выполните ту же PowerShell-команду. В новой таблице теперь две строки, с разными execution_id. Это два независимых сбоя. Время регистрации может отличаться от времени исходной ошибки; не используйте его как точный замер задержки без отдельного измерения.
Шаг 12. Сравните ручную ошибку и успешное выполнение
В ezGPT - Error Demo запустите ветку Manual Trigger вручную через её действие Test workflow/Execute workflow. Demo Failure снова упадёт, но число строк должно остаться два: Error Trigger в этом примере не запускается из ручной ошибки. POST к Test URL тоже не заменяет production-проверку.
Теперь временно выключите только Demo Failure через меню узла → Deactivate/Disable. Не отключайте весь workflow. Сохраните схему и снова опубликуйте её, дождитесь подтверждения. Отправьте тот же POST к Production URL. Новый запуск должен завершиться Success, а строк в журнале остаться две.
Включите Demo Failure обратно, сохраните и снова опубликуйте. Новый POST должен дать Error и третью строку. Если изменение ещё не действует, проверьте опубликованную версию: сохранённый черновик и запущенная production-схема могут различаться.
Шаг 13. Проверьте ошибку самого обработчика
Только в учебной схеме ezGPT - Error Log временно измените Data table у Save Error на несуществующее имя ezgpt_missing_error_table. Сохраните и опубликуйте обработчик. Отправьте ещё один POST. Исходная схема упадёт, но новая строка не сохранится: сам обработчик завершится Error в Save Error.
Проверьте Executions обеих схем. У обработчика должно быть одно новое ошибочное выполнение, а не непрерывная цепочка. В нашем экземпляре без отдельного Error workflow у обработчика самоповтор не возник. Это не универсальная защита от любых цепочек: не связывайте разные обработчики взаимно и не добавляйте бесконечные повторы.
Верните таблицу ezgpt_error_log в Save Error, сохраните и опубликуйте обработчик. Повторите POST: ожидается четвёртая сохранённая строка и Success у обработчика. Пропущенный при недоступной таблице сбой сам собой не восстановится. Такой журнал нельзя считать гарантированной доставкой.
Шаг 14. Проверьте сохранение и выключите демо
Если используете локальную Docker-установку из нашей инструкции, перезапустите её с сохранением данных:
Set-Location "$HOME/n8n-local"
docker compose restart n8n
docker compose ps
Дождитесь редактора, откройте таблицу и проверьте четыре прежние строки. Новый POST должен добавить пятую: обе схемы должны остаться опубликованными. Не удаляйте volume и не используйте down -v. На Cloud не выполняйте локальные команды; проверьте новое чтение таблицы без перезапуска сервиса.
Завершив тест, снимите публикацию ezGPT - Error Demo через действие Unpublish/Deactivate workflow. Новый POST к его Production URL должен вернуть 404, а число строк не измениться. Это ожидаемый финал: учебная точка входа отключена, журнал сохранён. Если обработчик больше ни к чему не подключён, его тоже можно снять с публикации.
Если результат отличается
| Симптом | Причина | Что проверить |
|---|---|---|
| POST вернул 404 | Не тот URL или нет публикации | POST, Production URL, опубликованная схема |
| Исходная схема Error, строк нет | Обработчик не запустился | Error workflow, Publish, права вызова |
| HTTP 200, затем Error | Respond Immediately | Статус именно в Executions |
| Manual Error без записи | Ручное выполнение | Повторите production POST |
| Save Error завершился Error | Таблица или колонки не совпали | ezgpt_error_log и семь строковых полей |
| Изменение узла не действует | Запускается опубликованная версия | Сохранить, опубликовать, дождаться подтверждения |
| Нет execution_id | Событие без сохранённого выполнения | Не считать пустое поле нулевым ID |
Перед подключением рабочих схем
В журнал не копируется полный error.message, но история Executions самого n8n всё равно может содержать входные данные и детали ошибки. Подготовка семи полей не очищает её автоматически. Согласуйте права, настройки сохранения выполнений, сроки хранения и резервные копии. Не называйте узлы и workflows паролями или персональными данными.
Обработчик подключают отдельно в Settings каждого нужного workflow. Не включайте массовое автоматическое повторение после ошибки: запрос мог уже создать документ или списать средства до сбоя. Сначала проверьте, какое действие завершилось, затем повторяйте только безопасную операцию с защитой от дублей.
Как настроить ограниченные повторы HTTP-запросов
Error Trigger не заменяет мониторинг доступности n8n и хранилища. Если процесс остановлен, нет соединения с базой или недоступен сам журнал, обработчик может не сохранить событие. До подключения платежей, удаления, публикации или отправки клиентам нужен независимый контроль, а не только эта учебная таблица.
Что проверено редакцией
13 октября 2026 года сценарий проверен на n8n 2.42.4 в отдельном локальном экземпляре, доступном только на 127.0.0.1. Двенадцать тестов: неопубликованный обработчик; production-сбой с опубликованным обработчиком; повторный POST; ручная ошибка без события; успешный POST без события; возврат ошибки; отсутствующая таблица без самоповтора; восстановление обработчика; подготовка синтетического trigger.error; подготовка события без execution.id; новый POST после перезапуска; 404 после снятия публикации. Таблица читалась отдельным workflow; пять финальных записей и соответствие ID проверены. События trigger.error и без ID были синтетическими тестами кода, не настоящими ошибками активации триггера. Ручной API запуск использовался для сравнения и чтения, production POST — для настоящего Error Trigger. Первая проба выявила необходимость публикации обработчика в этой версии; следующая — необходимость дождаться применения публикации. Финальный набор тестов прошёл. Cloud, аварийное завершение процесса, потеря базы, доставка при таких авариях и кликовые действия редактора n8n не тестировались. Рабочие workflows не менялись; учебный контейнер остановлен. Обложка — редакционная AI-иллюстрация.
Частые вопросы
Почему ручная ошибка не попадает в таблицу?
В этом сценарии Error Trigger срабатывает после автоматического выполнения, например POST к Production URL опубликованного Webhook. Ручной запуск и Test URL не являются эквивалентной проверкой.
Нужно ли публиковать обработчик?
В проверенном n8n 2.42.4 — да: без опубликованной версии он не запускался. Поэтому в инструкции опубликованы обе схемы. На другой версии проверяйте новое событие в Executions и таблице, а не только настройки.
Почему сервер вернул 200, хотя workflow упал?
Demo Webhook отвечает Immediately, до окончания цепочки. Ответ означает приём запроса. Итог работы нужно смотреть в Executions; обработчик не меняет статус упавшей исходной схемы.
Можно ли подключить один обработчик к нескольким workflow?
Да, назначьте его в Error workflow нужных схем и проверьте права вызова. workflow_id и workflow_name позволят различать источники. Сначала проверьте отдельную учебную копию каждой схемы.
Журнал гарантирует сохранение всех ошибок?
Нет. Сбой процесса, хранилища или самого обработчика может помешать записи. Insert также не обеспечивает неизменяемый аудит и защиту от повторной доставки события. Для рабочих систем нужен отдельный мониторинг и политика восстановления.