Retry on Fail и Continue on Fail

В настройках почти каждого узла в n8n есть две опции, связанные с обработкой ошибок: Retry on Fail (повторить при ошибке) и Continue on Fail (продолжить при ошибке). Это самый локальный уровень обработки — на уровне одного узла.

Примечание. Точные названия опций и их расположение в настройках узла могут меняться. Обычно они находятся в общих настройках узла (Settings) рядом с таймаутами и нотификациями. Принципы — ниже.

Retry on Fail: повторить, если не получилось

Если узел упал из-за временной ошибки — например, сервер ответил 503 Service Unavailable — есть смысл повторить запрос через секунду. Возможно, во второй раз получится.

В настройках узла можно включить повторы и задать:

Количество попыток — сколько раз повторить, если не получилось.
Задержку между попытками — пауза в миллисекундах перед следующей попыткой.

После исчерпания попыток узел всё равно «упадёт», и сценарий пойдёт по сценарию обработки ошибок (или просто прервётся).

Когда стоит включать:

Запросы к внешним API, которые иногда «моргают».
Операции с базой данных, которая может быть временно перегружена.
Любые сетевые операции с потенциальными таймаутами.

Когда не стоит:

Когда повтор может привести к дублированию (например, повторное создание заказа). В таких случаях нужна идемпотентность на стороне получателя — иначе повтор сделает второй заказ.
Когда ошибка явно постоянная (404, 401, 400) — повторяй не повторяй, ответ не изменится. К сожалению, n8n не всегда умеет различать «временную» и «постоянную» ошибку, поэтому повторы случаются и там, где не помогут.

Continue on Fail: продолжить, как ни в чём не бывало

Если вы включаете Continue on Fail, при ошибке узла:

сценарий не падает;
ошибка не пробрасывается дальше;
вместо нормальных данных на выход узла попадает информация об ошибке (отдельный объект, в котором описано, что произошло).

Это удобно, когда:

ошибка одного item не должна останавливать обработку остальных. Например, вы рассылаете 1000 писем — и одно не доходит. Остальные 999 должны быть отправлены.
вы хотите явно проверить, что вернул узел: ошибку или результат, и повести разные ветки сценария.

После такого узла обычно ставят IF, который проверяет, есть ли в данных признак ошибки, и направляет «успехи» в одну ветку, «неудачи» — в другую.

Сочетание

Часто Retry on Fail и Continue on Fail включают вместе:

сначала пытаемся повторить (3-5 попыток с растущей задержкой);
если не помогло — не падаем, а отправляем item в ветку «неудача» и идём дальше.

Это базовая защита от шума и сбоев, которая не требует отдельного сценария обработки ошибок.

Что выбрать

Простой рекомендуемый подход:

Внешние сетевые вызовы: включайте Retry (2-3 попытки, задержка 1-3 секунды).
Операции, где важен каждый item: включайте Continue on Fail и явно обрабатывайте сбои отдельной веткой.
Критичный сценарий целиком: дополнительно настройте Error Workflow (об этом — следующий урок).