За два с лишним года на поддержке проектов на Tilda, WooCommerce и кастомных SaaS я вывел правило: критичные сценарии работы сайта ломаются не потому что код плохой, а потому что после запуска их никто не трогает и не проверяет. Форма заявки полгода отправляла письма исправно, а после обновления плагина WooCommerce тихо перестала - и никто не заметил, пока клиент не написал в директ с вопросом, почему заказ так и не подтвердили. Ниже список сценариев, которые я регулярно проверяю на проектах, которые веду на поддержке, с конкретными сроками и признаками поломки.
Что считать критичным сценарием на сайте
Критичный сценарий - это цепочка действий, которая напрямую превращается в деньги или в заявку: оформление заказа, оплата, расчёт доставки, отправка формы, вход в личный кабинет, работа бота-ассистента. Если сценарий ломается, посетитель не пишет в поддержку и не звонит - он просто уходит к конкуренту. По моей статистике на проектах на Tilda и WooCommerce примерно 60% пользователей, столкнувшихся с ошибкой на этапе оплаты, больше не возвращаются на сайт вообще.
| Сценарий | Как часто проверять | Типичный симптом поломки |
|---|---|---|
| Оплата (эквайринг) | Раз в неделю + после каждого обновления плагина | Заказ уходит в статус «ожидает оплаты» и там зависает |
| Расчёт доставки | Раз в 2 недели | Стоимость доставки считается нулевой или не подгружается |
| Формы и заявки | Раз в неделю | Письмо не приходит, а на сайте показывается «спасибо» |
| Личный кабинет / авторизация | Раз в месяц | Письмо с кодом или паролем не доходит |
| Telegram-бот | Ежедневно (автоматически) | Бот не отвечает после сбоя вебхука |
Приём платежей: где реально теряют деньги
На связке T‑Bank и WooCommerce чаще всего ловлю три типа поломок. Первая - истекший или отозванный API-токен эквайринга, после чего плагин продолжает показывать форму оплаты, но платёж не проходит, а покупатель об этом не знает до последнего экрана. Вторая - забытый тестовый режим после доработки: сайт принимает «оплату», деньги реально не списываются, и это вскрывается только когда бухгалтерия сверяет отчёты за месяц. Третья - обрыв вебхука о статусе платежа, из-за которого заказ в CRM остаётся неоплаченным даже после успешного списания денег, и менеджер просто не берёт его в работу.
Проверяю это так: раз в неделю делаю тестовый заказ на минимальную сумму, смотрю, что статус в CRM меняется автоматически, а не руками. Если делать это самому некогда, разовая проверка обходится дешевле, чем недельная выручка, потерянная из-за незамеченного сбоя эквайринга.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Доставка и расчёт стоимости: СДЭК и зоны доставки в Tilda
СДЭК периодически меняет формат ответа API или отзывает токены доступа без предупреждения по почте - только уведомление в личном кабинете, которое никто не читает. Итог: калькулятор доставки на сайте либо показывает ошибку, либо, что хуже, тихо выдаёт нулевую стоимость, и заказы с бесплатной доставкой в другой конец страны начинают сыпаться в CRM пачками.
В Tilda отдельная головная боль - зоны доставки, настроенные через кастомный скрипт. Если менеджер вручную поправил список городов в панели Tilda и не учёл формат, который ждёт скрипт, расчёт слетает целиком, а не частично. У меня в библиотеке лежит уже собранный готовый скрипт зон доставки для Tilda, который проверяет входные данные и не даёт калькулятору обнулиться при опечатке в названии города - это закрывает добрую половину подобных инцидентов.
Отдельно проверяйте расчёт налогов и НДС, если у вас интернет-магазин с юрлицом: ошибка в округлении на копейки при тысяче заказов в месяц превращается в заметную сумму расхождений при сверке с бухгалтерией.
Формы и заявки: куда пропадают лиды
Форма на сайте - самый незаметный тип поломки, потому что визуально всё работает: кнопка нажимается, появляется «спасибо за заявку», а письмо никуда не уходит. Причины на практике почти всегда одни и те же:
- Сменился адрес приёма писем на хостинге, и SMTP начал молча отклонять исходящую почту.
- Обновился антиспам-плагин и стал резать письма с формы как спам, включая с самого сайта.
- В кастомном скрипте на Tilda поменяли ID полей при редизайне блока, а обработчик формы ссылается на старые.
- Вебхук из формы в CRM или в Telegram-бота перестал отвечать за отведённые 3-5 секунд, и Tilda просто откатывается на дефолтное поведение.
Проверяю форму так же, как оплату: раз в неделю реальная тестовая заявка с реального устройства, а не только через панель администратора. Если форма связана с CRM или таблицей через вебхук, полезно завести отдельный лог ошибок - без него сбой обнаруживается только со слов разозлённого клиента.
Боты и автоматизация: aiogram и n8n тоже требуют присмотра
Если у бизнеса есть Telegram-бот на aiogram, который принимает заказы или записи, критичный сценарий здесь один: доставка сообщения от пользователя до момента, когда его увидел живой человек. На вебхуках боты падают тихо - Telegram просто перестаёт слать апдейты, если сервер несколько раз подряд не ответил вовремя, а перезапуска никто не делает, потому что процесс формально жив в systemd.
С n8n похожая история: сценарий работает месяцами, а потом сторонний сервис в цепочке меняет формат ответа API или удаляет старую версию эндпоинта, и workflow падает без внятного оповещения, если алерты в канал не настроены отдельно. Я всегда добавляю в такие цепочки узел, который шлёт уведомление в отдельный чат при любой ошибке выполнения, иначе сценарий может простаивать неделями, пока кто-то не спросит, почему перестали приходить заявки.
Как выстроить регулярную проверку критичных сценариев
Ручной обход раз в неделю снимает основную часть рисков, но не спасает от сбоев, которые случаются между проверками, особенно у платёжных провайдеров и служб доставки. Практика, которая у меня закрывает 90% инцидентов:
- Автоматический мониторинг главных URL сайта (главная, корзина, чекаут) с проверкой раз в 5-15 минут и алертом в Telegram при ответе, отличном от 200.
- Ежедневный тестовый заказ на минимальную сумму через бота или скрипт, а не руками.
- Еженедельная проверка формы обратной связи с реального email и телефона.
- Ежемесячная сверка статусов в CRM с реальными платежами в личном кабинете эквайринга.
- Журнал ошибок вебхуков и ботов с уведомлением в отдельный канал, а не только в логи на сервере.
Настраивать это с нуля можно самостоятельно, но на практике проще один раз собрать чек-лист и мониторинг под конкретный стек проекта, а дальше просто получать алерты вместо того, чтобы вручную проверять каждый сценарий.
Чтобы сайт работал без сбоев
Техподдержка
от 15 000 ₽/мес
Подробнее →Частые вопросы
Как часто нужно проверять критичные сценарии на сайте?
Оплату и формы заявок - минимум раз в неделю, а после любого обновления плагинов, скриптов или интеграций - сразу же, не откладывая на «потом». Доставку и расчёт налогов достаточно проверять раз в 2 недели, если провайдер не менял API за это время.
Что делать, если форма заявки на сайте перестала отправлять письма?
Сначала проверьте, доходит ли заявка хотя бы в CRM или в базу данных - если да, проблема в почтовом уведомлении, а не в самой форме. Дальше смотрите логи SMTP и настройки антиспам-плагина, если он появился недавно. Если форма связана с кастомным скриптом на Tilda, чаще всего дело в изменившихся ID полей после редактирования блока в конструкторе.
Нужен ли отдельный мониторинг, если сайт сделан на Tilda?
Да, потому что Tilda не оповещает о сбоях сторонних интеграций вроде СДЭК, эквайринга или CRM-вебхуков - конструктор просто откатывается на дефолтное поведение блока, и внешне всё выглядит рабочим. Мониторинг ключевых сценариев через сторонний сервис или кастомный скрипт закрывает именно эту слепую зону.
Сколько стоит настроить регулярную проверку критичных сценариев?
Разовая консультация с разбором сценариев конкретного сайта стоит от 3 000 ₽. Если нужен постоянный присмотр с мониторингом, тестовыми заказами и логированием ошибок интеграций, это оформляется как техподдержка от 15 000 ₽ в месяц, объём подбирается под количество критичных сценариев на конкретном проекте.