Webhook с заявкой упал ночью на 502 от Bitrix REST, execution в n8n красный, а менеджер узнал об этом только когда клиент написал «я оставлял заявку». Error Workflow не был привязан, Retry On Fail стоял «на глаз», и при повторе в CRM появился дубль лида. За один вечер вы подключите отдельный обработчик ошибок, настроите разумный retry с паузами, соберёте алерт в Telegram с execution id и защитите CRM ключом идемпотентности - чтобы утром не искать потерянные лиды.
Это runbook для владельца пайплайна заявок, а не обзор всех способов error handling в n8n. Мы не трогаем сбор webhook и маршрутизацию - только слой «что делать, когда flow уже упал». n8n (no-code автоматизатор с узлами-нодами) умеет ловить сбой отдельным workflow и повторять transient ошибки API на уровне ноды - но эти механизмы легко перепутать.
Тут важный момент из официальной документации n8n (июль 2026): если workflow содержит узел Error Trigger, по умолчанию он назначает сам себя Error Workflow. Плюс Error Workflow не перезапускает упавший execution автоматически - community в феврале 2026 снова подтвердила: только алерт, ручной replay или отдельный sub-workflow. Retry On Fail и Error Trigger - разные инструменты, не взаимозаменяемые.
Привяжите Error Workflow к production-flow с заявками
Боль: заявка потеряна, никто не узнал о сбое. Решение: отдельный workflow-обработчик, который стартует только когда основной упал.
- Создайте workflow Error Handler с узлом Error Trigger в начале.
- Добавьте Set: нормализуйте поля workflow.name, execution.id, execution.url, execution.lastNodeExecuted, execution.error.message.
- IF-фильтр: игнорируйте тестовые workflow по имени, чтобы не ловить шум.
- В production-workflow с заявками: Options -> Settings -> Error workflow -> выберите Error Handler -> Save.
- Убедитесь, что handler не ссылается сам на себя без guard - иначе рискуете петлёй.
Payload Error Trigger по docs.n8n.io включает execution id, url, текст ошибки и lastNodeExecuted. Если ошибка случилась в trigger-ноде, id и url могут отсутствовать - учитывайте это в шаблоне алерта. Error workflow не обязан быть опубликован; ручной Test workflow Error Trigger не запустит - это нормально. Важно: рекомендуем один общий Error Handler на все production-flows с заявками, а не отдельный черновик на каждый сценарий.
Типичная ошибка: ждут, что Error Workflow сам «перезапустит» заявку. Нет - он шлёт сигнал ops. Автоповтор делает Retry On Fail на ноде или отдельный scheduled workflow по API (шаблон Auto-retry Engine #3144 на n8n.io). В реальном проекте интегратор включил Retry на 5 попыток без задержки и не привязал Error Handler - после rate limit 429 n8n создал пять дублей, а когда нода упала окончательно, алерта не было.
Настройте Retry On Fail для CRM и HTTP с лимитом и backoff
Боль: transient 502 или 429 роняет весь пайплайн одной ночью. Решение: повтор только на временных сбоях API, с паузой между попытками.
| Тип ошибки HTTP | Retry On Fail | Почему |
|---|---|---|
| 429, 502, 503, 504 | Да, 3 попытки | Временный перегруз или сеть - часто проходит через 30-120 сек |
| 400, 401, 403, 422 | Нет | Неверные данные или токен - повтор только жжёт лимиты |
| CRM create без idempotency | Нет, пока нет ключа | Каждый retry = риск второго лида |
На HTTP/Bitrix/CRM-нодах: Settings -> Retry On Fail -> Max Tries 3, Wait Between Tries 30000-120000 ms (30-120 сек). Backoff 30 / 120 / 600 сек - разумный старт для Bitrix REST. Не включайте retry на нодах с side-effect (создание лида), пока не готов ключ идемпотентности. Советуем сначала прогнать mock 500 на копии flow, а потом включать retry на проде.
Continue on Fail поглощает ошибку - Error Workflow при этом не сработает (getnodey.com). На CRM create держите Continue on Fail выключенным; не делайте так на production-нодах с side-effect. Лучше явный fail и алерт, чем тихий success. Если retry исчерпан, заложите ветку DLQ: Google Sheet или Postgres с payload, error_code, execution_id, owner - для ручного replay, не для бесконечного цикла.
Схема трёх слоёв:
Retry On Fail (нода) -> поймать transient на месте
Error Workflow (workflow) -> алерт ops, когда всё упало
DLQ (таблица) -> ручной разбор «ядовитых» заявок
Соберите алерт в Telegram или Slack без утечки PII
Боль: error handler падает сам или шлёт шторм нечитаемых сообщений. Решение: минимальный handler без тяжёлых нод и один понятный алерт на инцидент.
- После Set в Error Handler добавьте Telegram или Slack.
- В текст включите: имя workflow, execution id, ссылку execution.url, lastNodeExecuted, error.message.
- Не вставляйте в алерт телефон, email и полный body заявки - только технические поля.
- Опционально: запись в Sheet/Postgres без PII для журнала инцидентов.
На практике хватит шаблона: «FAIL: {workflow} / node {lastNode} / {message} / open {url}». GitHub issue #25923 напоминает: алерт должен отличать infra-сбой (runner crash-loop) от API 502 - по lastNodeExecuted и тексту ошибки. Throttle на уровне IF: не слать повтор, если тот же workflow упал три раза за минуту.
Защитите CRM ключом идемпотентности перед create
Боль: ретрай создаёт второй лид в CRM. Решение: один внешний ключ на заявку и проверка перед create.
- Code node перед CRM: соберите idempotency_key из email, phone или request_id формы.
- HTTP GET или search: есть ли лид с таким ключом (UF-поле, внешний ID, комментарий).
- IF exists -> ветка update или skip; else -> create.
- При update передавайте тот же ключ - CRM не размножит дубли.
Идемпотентность (повторный вызов не меняет результат) - страховка, когда Retry On Fail всё же отработал дважды. Без ключа даже один «умный» retry опасен: Bitrix lead.create не знает, что это та же заявка. Типичная ошибка: включили 5 retry без паузы на 429 - CRM получила пять одинаковых лидов за секунду.
Прогоните чек-лист: mock 500, алерт, один лид в CRM
Боль: Error Trigger «не срабатывает» при ручном тесте. Решение: тест через активный trigger и Stop and Error, не через Execute Workflow.
Success criteria - вы на финише, если:
- После тестового сбоя (Stop and Error или mock 500) за 2 минуты приходит алерт с именем workflow, execution URL, last node и error message.
- Retry On Fail отрабатывает только на transient (429/5xx); в Executions видно retryOf.
- В CRM остаётся один лид с тем же idempotency key после N попыток.
- Финальный статус - success или запись в DLQ, не тишина.
- В копии workflow вставьте Stop and Error с message TEST_ALERT_B40, активируйте.
- Дождитесь алерта в Telegram - проверьте поля и ссылку execution (цель: до 40 сек).
- Mock HTTP: два ответа 500, затем 200 - убедитесь в retryOf и одном лиде.
- Искусственный 401 - retry не должен крутиться, только алерт и фикс credentials.
- На self-hosted: загляните в docker logs n8n и retention Executions - FAQ ниже.
Итог: после чек-листа вы сможете спать спокойно - алерт придёт за минуты, в CRM останется один лид. Что дальше: привяжите Error Handler ко всем критичным flows с заявками; вынесите credentials в Variables; при росте нагрузки смотрите шаблон hourly Auto-retry Engine - это дополнение, не замена node-level retry. Нужен разбор вашей воронки под Bitrix или другую CRM - на calmopsai.com. Базовый приём webhook без обработки сбоев - в гайде по n8n Webhook.
Материал проверен: эксперт Алексей Доронин (автоматизация бизнеса и ИИ).
Достоверность данных: факты по Error Workflow, Error Trigger, Retry On Fail, Continue on Fail и отсутствию native restart сверены с docs.n8n.io, community.n8n.io и nodbot.ru на 31 июля 2026. Объёмы Wordstat в этом прогоне не верифицированы (API недоступен) - частотности не выдумывались.
Частые вопросы
Чем Error Trigger отличается от Error Workflow?
Error Trigger - узел в начале отдельного workflow, который принимает данные о падении. Error Workflow - настройка в Settings production-flow: «какой workflow запустить при ошибке». Один handler обслуживает много flows; Trigger без привязки ничего не поймает.
Сколько ретраев ставить на Bitrix REST?
Старт: 3 попытки, пауза 30-120 сек между ними. На 429 увеличьте wait, не count. На 401/400 retry выключите - чините токен и поля, иначе получите лавину бесполезных executions.
Почему Error Workflow не срабатывает при ручном Test workflow?
Так задумано в docs: Error Trigger реагирует на реальное падение активного workflow, не на кнопку Test. Используйте активный webhook/cron и Stop and Error или mock API 500 в копии flow.
Куда смотреть логи на self-hosted n8n?
Executions в UI - первый экран: id, retryOf, last node, error message. На своём сервере - docker logs контейнера n8n; проверьте retention, чтобы ночной сбой не исчез из истории через сутки.
Может ли Error Workflow сам перезапустить заявку?
Нет встроенного restart. Error Workflow - алерт и логирование. Повтор делает Retry On Fail на ноде, ручной replay из Executions или отдельный scheduled workflow по n8n API (шаблон #3144).
Continue on Fail мешает алертам?
Да. Если нода глотает ошибку через Continue on Fail, основной workflow считается успешным - Error Workflow не запустится. Для CRM create держите строгий fail и отдельный handler.