5 проверок, без которых ваш n8n-workflow — бомба замедленного действия

Workflow отработал. Зелёная галочка. Success. А через две недели клиент звонит: «Почему из 200 лидов обогатились 3?»

Ответ: потому что workflow не упал — он тихо сломался. Silent failure. Самый дорогой тип ошибки в автоматизации: вы не знаете о проблеме, пока не стало поздно.

В Reddit-сообществе n8n эту тему подняли прямо: «A workflow works on the happy path, but it is nowhere near production-ready». Я собрал чеклист из 5 проверок, которые превращают демо-автоматизацию в production-grade решение.

Алерт на ошибку — это гигиена. Но тихий отказ выглядит иначе: workflow обрабатывал 40 записей, а теперь обрабатывает 2. Ошибок нет. Просто API выше по цепочке стал отдавать меньше данных.

Решение: логируйте records_processed на каждом прогоне. Поставьте пороги. Если объём упал на 80% — это не «мало данных», это сигнал.

В n8n: IF-нода после обработки → проверка $items.length → алерт в Slack или Telegram.

Workflow запустился, прошёл все ноды, обработал 0 записей. Success. Нормально ли это?

Может быть. А может — токен истёк, API поменял эндпоинт, и ваш HTTP Request получает 200 с пустым телом.

Правило: если 3 прогона подряд вернули ноль записей — это не «нет новых данных». Это проблема, которая требует внимания.

HTTP Request нода в n8n по умолчанию не имеет жёсткого таймаута. Внешний API не отвечает — workflow зависает. Если он в цепочке — зависает всё.

Что делать: - Options → Timeout → 10–15 секунд для критичных вызовов - Options → Retry On Fail → 2–3 попытки - Проверяйте тело ответа: 200 с {"error": "rate_limit_exceeded"} — не успех

Я ставлю таймаут на каждый внешний вызов. Без исключений. Потому что «всегда быстрый» API однажды перестанет быть таким.

API поменял email на contact_email. Поле price стало строкой вместо числа. Webhook пришёл без order_id.

Workflow не упал — записал undefined в CRM. Вы узнали через неделю.

Решение: Code-нода с валидацией сразу после получения данных. Проверяйте обязательные поля, типы, диапазоны. Невалидные записи — в dead-letter таблицу, а не в мусор. Потому что их можно переобработать после исправления.

Workflow зависит от версий API, структуры данных, токенов, настроек n8n и других workflow. Обновился n8n — нода поменяла поведение. Обновился Stripe API — поля переименовались.

Заведите тестовый набор данных (фикстуры) для каждого workflow. После любого изменения — прогоните и сверьте результат. Добавьте manual trigger для ручного перезапуска: когда что-то ломается, возможность быстро переотправить данные без восстановления контекста — это спасение.

Пять проверок: - Мониторинг объёма — ловит деградацию до того, как клиент заметит - Алерт на пустоту — ловит молчаливую смерть источника данных - Таймауты — не даёт одному зависшему API уронить весь пайплайн - Схема-валидация — ловит изменения в структуре данных - Тест зависимостей — ловит поломки после обновлений

Внедрение всех пяти — 2–3 часа на workflow. Ничто по сравнению с неделей разбора «как мы потеряли 400 лидов и никто не заметил».

Какие проверки вы добавляете в свои n8n-workflow перед продакшном?