Настройки воркфлоу в документации n8n я открыл ради одной вещи: понять, что будет, если сценарий упадёт посередине. Нашёл строку “the workflow resumes from where it stopped in case of an error” и на минуту успокоился. Зря: строка отвечает не на тот вопрос, который я задавал.

Меня зовут Александр Жогов, я руковожу компанией “+Альянс”, мы делаем сервисы вокруг облачного офиса Яндекс 360. Названий своих продуктов дальше не будет - речь про чужую документацию и про способ её читать. Дата сверки везде одна, 27 августа 2026 года, ссылки стоят прямо в тексте. Документация n8n живёт без номеров версий, так что если страница поменялась - считайте мою сверку устаревшей и смотрите сами.

Почему меня вообще волнует падение посередине

Если сценарий всего лишь рассылает письма, цена сбоя - лишнее письмо. Как только в сценарии появляется шаг “удалить учётную запись”, вопрос звучит иначе: что движок делает сам, а что молча оставляет на мне.

Проверяю я по шести вопросам. Взяты они не с потолка: это раздел “Надёжность” технической документации системы автоматизации, которую делает моя команда, - валидация графа, повторы при сбоях, идемпотентность необратимых действий, безопасный перезапуск с точки сбоя, ожидание завершения резервного копирования перед необратимым шагом, ограничение одновременных запусков на организацию. Каждую строку я и превращаю в вопрос к чужой документации.

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

Почему именно n8n. По исходному плану он должен был работать у нас под капотом, со слоем абстракции сверху; собственный движок стоял следующим этапом, на переезд закладывался год. Вышло иначе - до промежуточного этапа дело не дошло. Но читали мы n8n не по диагонали: на нём собирались стоять.

Комментарий “возьмите Temporal или Airflow и не изобретайте велосипед” я предвижу и спорить не стану. Фактов ни о Temporal, ни об Airflow у меня нет, сравнивать их с чем-либо я не возьмусь. Шесть вопросов ниже я задаю не ради того, чтобы уесть готовые движки: их получает любой инструмент, включая мой собственный.

Первая проверка: кнопка Retry execution

Save execution progress - настройка уровня воркфлоу, она описана так: “Whether n8n should save execution data for each node. If set to Save, the workflow resumes from where it stopped in case of an error. This may increase latency”.

Но повтор упавшего запуска в n8n живёт ещё в одном месте - в списке выполнений есть кнопка Retry execution. Страница про список описывает у неё два варианта, “Retry with currently saved workflow” и “Retry with original workflow”, и оба переиспользуют данные предыдущего запуска. Продолжится ли выполнение с упавшего узла, страница не сообщает ни в одну сторону.

Два механизма, похожие слова, разный смысл - и ни в одном месте не написано, какой из них накрывает мой случай. Дальше пришлось идти на форум.

Декабрь 2021: “разница видна, только когда падает всё”

В ветке про эту самую настройку участник форума MutedJam 9 декабря 2021 года объясняет: “The difference will only be visible if your entire workflow/instance crashes (and not just a single node failing…)”; “n8n will write and load the execution progress to/from the database after each step”.

Вот и ответ на мой вопрос, только неудобный. Речь про крах всего инстанса, а не про падение одного узла в штатно работающем n8n. Строка из документации формально верна - я просто прочитал её шире, чем она написана.

Ещё две ветки, и вопрос закрыт

Свежее и прямее. Автор темы про восстановление после сбоя mohamedelnady-406 4 декабря 2025 года спрашивает без обиняков: “how can I ensure that after an unexpected server crash, the workflow execution automatically resumes from the exact node where the failure happened”. Ответ участника форума daniel_Samuel в тот же день: “you can’t guarantee automatic resume from the exact failed node after a server crash with default settings in a self hosted instance”, и следом: “i don’t think n8n is designed as a fully resilient, transactional workflow engine like apache air workflow with checkpointing” (в оригинале опечатка, по контексту Apache Airflow).

Отдельно оговорюсь: это реплики участников форума, не документация и не официальный ответ вендора. Статус авторов бейджем на странице я подтвердить не смог.

Цена вопроса на практике видна в апрельской ветке 2026 года. Её автор Keira_Becky описывает свой случай так (пересказ близко к тексту): если падение случается на двадцатой странице, начинать приходится с первой. А спрашивала она вот о чём: “Is there a recommended architecture or pattern for making workflows safely resumable?” Человек просил не функцию, а паттерн. Вот вам и ответ, чья это ответственность.

В той же ветке отвечает участник форума Niffzy: “Your workflow has no state, so when it fails, it restarts blindly duplicates and skips”. Рекомендация там же - держать прогресс в собственной внешней базе и продолжать по ней.

Ладно, перезапуск - на мне. Что ещё?

Дальше я прошёл оставшиеся пять вопросов подряд, уже без иллюзий.

Повторы: тумблер нашёлся сразу, политика - нет

Retry On Fail живёт в настройках ноды: “When an execution fails, the node reruns until it succeeds” - так это описано на странице про работу с нодами. Конкретика - на странице типовых проблем HTTP Request: “Set Max Tries to the maximum number of times n8n should retry the node. Set Wait Between Tries (ms) to the desired delay in milliseconds between retries. For example, to wait one second before retrying the request again, set Wait Between Tries (ms) to 1000”.

Задержка - одно число в миллисекундах, одинаковое для всех попыток. Слово “exponential” на этой странице не встречается ни разу, проверял целевым запросом 27 августа 2026 года.

Рядом лежат три варианта поведения при ошибке (On Error): Stop Workflow - “Halts the entire workflow when an error occurs, preventing further node execution”, Continue - “Proceeds to the next node despite the error, using the last valid data”, Continue (using error output) - “Continues workflow execution, passing error information to the next node for potential handling”. Есть и отдельный обработчик: “For each workflow, you can set an error workflow in Workflow Settings. It runs if an execution fails”, начинаться он обязан с Error Trigger, и один обработчик разрешено вешать на несколько воркфлоу.

Инструментарий богатый. Политику повторов из него собирает автор потока - по каждой ноде отдельно, руками. В моём списке этот пункт записан как обязанность платформы, с экспоненциальной задержкой; в n8n это выбор человека за холстом.

Слова “idempot” нет нигде в индексе документации

Автоматизация поверх облачного офиса живёт на опросе журнала событий: механизма подписки документация Яндекс 360 API не описывает (ниже об этом со ссылками), так что поток узнаёт о случившемся тогда, когда сам спросил. Мой вывод из чтения таких схем: повторная доставка одного и того же события в них - штатная ситуация, а не авария. И если на повторе стоит “удалить сотрудника”, отменять второе удаление уже некому.

Так что здесь я сразу снизил планку: хватило бы упоминания. Поиск по полному индексу документации, https://docs.n8n.io/sitemap.md, на “idempot” даёт ноль совпадений - не на одной странице, а во всём индексе. Страница ноды Webhook посвящена методам, путям, аутентификации и форматам ответа; про второй приход одного и того же события там ничего.

Из этого не следует, что дедупликации нет внутри. Следует ровно одно: искать её в документации бесполезно, а планировать работу приходится по документации.

Не удалить, пока копия не снята

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

Строительный материал у n8n документирован хорошо. У Wait-ноды четыре режима возобновления: After Time Interval, At Specified Time, On Webhook Call, On Form Submitted. Для вебхука и формы есть Limit Wait Time - автоматическое возобновление, если ожидаемое событие так и не случилось. Там же техническая деталь, которую полезно знать заранее: “For wait times less than 65 seconds, the workflow doesn’t offload execution data to the database”. И есть execution.resumeUrl - “The webhook URL to call to resume a waiting workflow”, доступный только в паре с ожиданием вебхука.

Цикл “спросить статус копии → подождать → спросить снова” из этих кубиков собирается. Собирает его автор потока: как соберёт, так и подождёт.

Дальше зона, где ответа я не нашёл. Таймаут выполнения задаётся переменной EXECUTIONS_TIMEOUT: “A workflow times out and gets canceled after this time (in seconds)”, по умолчанию -1, сверху есть потолок EXECUTIONS_TIMEOUT_MAX. Как этот таймаут считается для выполнения, которое в данный момент стоит на Wait, страница не объясняет - на 27.08.2026 этого там нет. При ожидании в десятки минут вопрос перестаёт быть теоретическим.

Смежную проблему форум обсуждает предметно. 21 февраля 2025 года участник форума rodrigoscdc пишет: “I realize if I use an amount of time in wait node greater than 64 seconds always will timeout in the initial request”. Участник форума Exnav29 отвечает: “The issue you’re facing is due to n8n’s webhook timeout limit, which defaults to 60-64 seconds for synchronous responses”, и предлагает поднять N8N_WEBHOOK_TTL до 300. Автор темы возвращается через три дня: с TTL 120 ответ всё равно не доходит, если ожидание дольше 65 секунд.

Один клиент запустил операцию на весь штат. Что с остальными?

Мультитенантная история. Представьте: один клиент запустил массовую операцию сразу по всему своему штату, а рядом, на том же инстансе, у второго идёт увольнение с резервной копией.

Страница про конкурентность в self-hosted начинается честно: “In regular mode, n8n doesn’t limit how many production executions may run at the same time. This can lead to a scenario where too many concurrent executions thrash the event loop, causing performance degradation and unresponsiveness”. Лимит включается переменной N8N_CONCURRENCY_PRODUCTION_LIMIT, одной на весь инстанс. Всё сверх лимита встаёт в очередь и разбирается в порядке FIFO. И строка, которую стоит прочитать дважды: “You can’t retry queued executions. Cancelling or deleting a queued execution also removes it from the queue”.

В облаке лимит выдаётся по тарифу: “n8n limits the number of concurrent executions for Cloud instances according to their plan”. Сами числа страница не приводит, отсылает к тарифам. Лимит видно в разрезе проекта, но отдельного лимита на проект или клиента страница не описывает.

Я проверил двух кандидатов на изоляцию. Страница Isolate n8n - про запрет самому инстансу ходить на серверы n8n (телеметрия, обновления, шаблоны): “prevents your n8n instance from connecting with n8n’s servers”; к разделению клиентов она отношения не имеет, хотя название обещает обратное. Projects и RBAC - про права: “n8n uses projects to group workflows and credentials, and assigns roles to users in each project”. Это защита от ошибки коллеги по команде, вещь полезная. Делят ли два проекта одну очередь и один лимит, страница молчит.

Оговорюсь: жалобы “сосед по очереди меня тормозит” я ни в одной ветке форума не нашёл. Это риск, вычитанный из документации, а не случившийся инцидент.

И самое скучное - проверка графа до запуска

Хотелось знать, остановит ли меня система, если я нарисовал цикл без выхода или узел, до которого исполнение никогда не дойдёт. В полном индексе документации https://docs.n8n.io/sitemap.md слов “cycle” и “valid” в путях страниц нет вообще, “loop” ведёт на страницу про циклы и на страницу ноды Loop Over Items. На странице про циклы ответственность за остановку лежит на авторе: условие выхода строится вручную через IF-узел. Единственная фраза про самостоятельную остановку относится к конкретной ноде - Loop Over Items заканчивает работу, когда разложила все входящие элементы по батчам и передала дальше.

Осторожность тут нужна отдельная. Страница про публикацию воркфлоу описывает статус “Published, error”: воркфлоу опубликован, но в последних изменениях есть ошибки, которые надо исправить перед следующей публикацией. Что именно входит в это “errors”, страница не раскрывает - может, и проверка графа. Поэтому честная формулировка одна: описания автоматической проверки на циклы и недостижимые узлы в документации на 27.08.2026 нет. Делается ли такая проверка на самом деле, я не знаю.

Что нашлось - одной таблицей

Здесь я бессилен, и вы тоже

Механизма подписки на события платформы документация Яндекс 360 API не описывает - сверял 27 августа 2026 года. Прямой URL https://yandex.ru/dev/api360/doc/ru/concepts/webhooks отдаёт 404, а в полном оглавлении https://yandex.ru/dev/api360/doc/ru/llms.txt не встречаются ни “webhook”, ни “notification”, ни “subscription”. События организации вычитываются опросом журнала аудита, с задержкой на цикл опроса. Обвязку поллинга придётся строить с любым движком - готовым, самописным, каким угодно.

Календаря и Форм в том же оглавлении документации Яндекс 360 API нет вовсе - ни по-русски, ни по-английски. Отсюда асимметрия, с которой живём и мы: положить встречу в календарь наша система умеет, потому что ходит туда по CalDAV, мимо API 360. Узнать, что приглашение приняли или что человек отправил ответ на форму, ей неоткуда. Писать - можем, читать - нет.

Вендора я тут ни в чём не упрекаю. Платформа устроена так, как устроена, и я говорю ровно о том, что написано на её страницах в конкретный день.

Место, где я проигрываю всухую

Документация n8n пишет о себе: “n8n supplies hundreds of nodes to create workflows that link multiple products”. Нода определена там широко - “Nodes are the building blocks of workflows in n8n”, а сам каталог та же страница раскладывает на библиотеки “Core nodes, Actions, and Triggers”: в счёт нод у n8n входят и действия, и триггеры. Плюс HTTP Request как универсальная отмычка: “It allows you to make HTTP requests to query data from any app or service with a REST API”, в том числе “Credentials for integrations not supported by n8n”.

У системы, которую делает моя команда, 18 триггеров и 17 действий, и универсальный исходящий HTTP-узел входит в эти семнадцать. Сотни против десятков - порядок величин разный, и этого пункта в моём списке из шести вопросов нет вовсе. Если задача формулируется как “связать между собой десяток разных SaaS”, шесть гарантий надёжности тут ничего не отыгрывают.

Слабое место этого текста

Назову его сам, до комментариев.

Всё, что здесь сказано про n8n, проверяется по ссылкам за вечер: страницы документации и ветки форума открываются без регистрации, даты сверки указаны. Всё, что здесь сказано про мою сторону, вы не проверите никак - ни одной ссылки я не дал и не дам, потому что внутреннюю механику мы наружу не отдаём. По моему же чек-листу моя система для читателя выглядит обещанием. Тем самым, которое я советую не принимать на веру.

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