Мониторинг форм на сайте я обычно настраиваю уже после первого случая, когда клиент говорит «а у нас неделю не было заявок» и никто до этого не заметил проблему. Форма может выглядеть рабочей: кнопка нажимается, поля заполняются, страница не падает, а данные никуда не уходят. За практикой на проектах на Tilda и WordPress я собрал рабочую схему проверки, которая ловит такие сбои за 5-10 минут, а не спустя неделю тишины.
Почему форма может молчать, а вы об этом не узнаете
Форма на сайте не присылает алерт «я сломалась». Она просто перестаёт передавать данные дальше, а внешне всё остаётся как было. Причин у меня на практике встречалось несколько:
- истёк токен интеграции с CRM или сервисом доставки, и вебхук возвращает ошибку авторизации, которую никто не видит
- почтовый ящик, куда шли уведомления о заявках, упёрся в квоту или письма стали улетать в спам после смены DNS-записей
- после редизайна или обновления плагина в JS-код закралась ошибка, и обработчик отправки формы перестал срабатывать
- у платёжного шлюза изменились реквизиты вебхука, и заказы из WooCommerce перестают долетать до склада или 1С
- антиспам-плагин или капча стали блокировать часть легитимных отправок вместе с ботами
Каждая из этих поломок не ломает сайт целиком, поэтому её не поймает обычный аптайм-мониторинг, который просто проверяет, что главная страница отвечает 200‑м кодом. Нужна отдельная проверка именно формы и всей цепочки до момента, когда заявка попадает к менеджеру.
Три уровня мониторинга форм на сайте
Я делю проверку на три уровня, и каждый ловит свой тип сбоя. Ни один из них не заменяет остальные полностью.
| Способ проверки | Что показывает | Как быстро находит сбой |
|---|---|---|
| Проверка доступности страницы и формы | Сайт вообще открывается, форма отрисовывается, скрипты не выдают ошибку в консоли | Обычно в течение нескольких минут после падения |
| Тестовая отправка с реальными данными | Форма реально принимает и передаёт данные на бэкенд или во внешний сервис | Зависит от частоты запуска теста, у меня обычно раз в 15-30 минут |
| Контроль приёма в CRM, на почте или в мессенджере | Заявка долетела до конечной точки, а не потерялась на середине пути | Можно проверять почти в реальном времени через вебхуки |
Первый уровень самый дешёвый в настройке, но и самый слепой: он не заметит, что форма открывается, но кнопка «Отправить» ничего не делает. Второй и третий уровни требуют больше настройки, зато ловят именно те сбои, из-за которых реально теряются деньги.
Технические способы проверки: от пинга до тестовой заявки
Проверка доступности страницы с формой
Это базовый уровень: сервис аптайм-мониторинга каждые несколько минут запрашивает страницу с формой и проверяет код ответа и время загрузки. Полезно, но покрывает только полную недоступность сайта. Я обычно добавляю сюда ещё проверку конкретного JS-файла, который отвечает за отправку формы: если файл не отдаётся с сервера, форма визуально на месте, а работать не будет.
Тестовая отправка с реальными данными
Здесь я настраиваю скрипт, который раз в 15-30 минут реально отправляет POST-запрос на адрес обработки формы с тестовыми данными, а потом проверяет ответ. Для формы на своём бэкенде это можно сделать простым curl-запросом:
curl -i -X POST https://your-site.ru/form-endpoint \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "name=Monitoring+Test&phone=%2B79990000000&email=monitor%40your-site.ru"Если ответ не 200 или тело ответа не совпадает с ожидаемым, скрипт кидает сигнал в систему алертов. Для форм на Tilda или в конструкторах, где нет прямого доступа к обработчику, тестовую отправку делаю через безголовый браузер: он открывает страницу, заполняет поля и жмёт кнопку отправки по-настоящему, как это сделал бы посетитель.
Контроль приёма заявок в CRM и на почте
Самая частая причина «тихой» потери заявок не в самой форме, а дальше по цепочке: заявка ушла с сайта, но не долетела до CRM или почты. Тут работает встречная проверка: если тестовая заявка не появилась в CRM или в почтовом ящике в течение оговорённого времени после отправки, значит проблема на стороне интеграции, а не сайта. Для проектов с оплатой через T‑Bank и синхронизацией заказов в WooCommerce я обычно добавляю отдельный лог вебхуков: каждый входящий вебхук от платёжной системы или от СДЭК пишется в отдельную таблицу с меткой времени, и если за час не пришло ни одного события при том, что заказы точно были, это тоже повод для алерта.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Особенности мониторинга на Tilda и WordPress
На Tilda формы уходят через встроенный сервис formsubmit или через интеграции, настроенные в панели сайта, поэтому проверять стоит не только фронтенд, но и то, куда конкретно настроена отправка: на почту, в CRM через API или в Telegram через кастомный скрипт. У меня в практике был случай, когда клиент сменил адрес почты в личном кабинете, а в блоке формы остался прописан старый адрес получателя, и заявки полгода уходили в ящик, который никто не проверял. Отдельный скрипт-дублёр, который параллельно с основной отправкой формы шлёт уведомление в Telegram, закрывает такие ситуации и стоит как небольшая доработка.
На WordPress источников сбоя больше: форма может быть на Contact Form 7, на встроенной форме WooCommerce для заказа, или сделана кастомным кодом в теме. Здесь чаще всего форма ломается после обновления плагина или темы, поэтому проверку стоит гонять не только по расписанию, но и сразу после каждого обновления. Для интернет-магазинов на WooCommerce отдельно слежу за вебхуками оплаты и статусами заказа: если вебхук от платёжной системы перестал приходить, заказы формально создаются, но зависают в статусе «ожидает оплаты» даже после реального списания денег.
Куда присылать алерты: Telegram и n8n
Просто найти сбой мало, нужно, чтобы о нём узнали быстро и без необходимости заходить в панель мониторинга. Проще всего собрать это на связке из тестового запроса к форме и уведомления в Telegram. Для несложных сценариев я пишу небольшого aiogram-бота, который раз в заданный интервал дергает эндпоинт формы и в случае ошибки шлёт сообщение в рабочий чат с указанием, что именно не ответило.
Когда проверок несколько и они разные по логике, удобнее собрать это не отдельными скриптами, а одним workflow. Для таких сценариев я обычно настраиваю автоматизацию в n8n: нода с расписанием запускает проверку, HTTP-запрос дергает форму или эндпоинт CRM, следующая нода сравнивает ответ с ожидаемым, а при отклонении срабатывает нода отправки в Telegram или на почту ответственному менеджеру. Плюс такого подхода в том, что все проверки видно в одном месте, и в них легко добавить новую точку контроля без переписывания кода с нуля.
Что делать, когда заявки действительно пропали
Если алерт сработал или менеджер сам заметил тишину, порядок действий у меня такой:
- проверяю саму форму на сайте вручную, отправляю тестовую заявку с телефона и с компьютера
- смотрю логи сервера или консоль браузера на ошибки JS в момент отправки
- проверяю статус интеграций: не истёк ли токен CRM, не изменился ли адрес вебхука у платёжной системы или у СДЭК
- проверяю папку «Спам» и настройки почтового ящика, если уведомления идут на почту
- смотрю, не поменялись ли настройки антиспам-плагина или капчи после последнего обновления
Обычно причина находится на одном из первых трёх шагов. Дольше всего искать сбои, которые связаны с истёкшим сроком действия токена стороннего сервиса: внешне всё работает, форма принимает данные, а дальше по цепочке они просто не идут, потому что сервис на том конце отвечает ошибкой авторизации, которую никто не логирует.
Если мониторинг форм и проверку интеграций держать на себе постоянно, это отдельная задача, которая требует внимания хотя бы раз в неделю даже без сбоев. На часть проектов я беру такие проверки на техподдержку от 15 000 ₽ в месяц: туда входит и наблюдение за формами, и быстрая реакция на сбой без необходимости объяснять контекст с нуля каждый раз.
Частые вопросы
Как часто нужно проверять форму, чтобы не терять заявки
Для большинства проектов хватает проверки доступности раз в 5 минут и тестовой отправки раз в 15-30 минут. Для интернет-магазина с большим потоком заказов интервал тестовой отправки я сокращаю до 10-15 минут, потому что цена простоя там выше.
Что делать, если письма с заявками попадают в спам
Проверяю настройки SPF, DKIM и DMARC для домена, с которого уходят уведомления, и по возможности перевожу отправку на транзакционный почтовый сервис вместо обычного ящика. Параллельно добавляю дублирующий канал уведомлений, например в Telegram, чтобы не зависеть от одной точки отказа.
Можно ли мониторить формы без разработки, готовыми сервисами
Базовый аптайм-мониторинг страницы настраивается без кода за несколько минут в любом сервисе такого типа. А вот тестовую отправку с реальными данными и сверку с приёмом в CRM обычно приходится собирать отдельно под конкретную форму и конкретную интеграцию, потому что у каждого проекта своя цепочка передачи заявки.
Как понять, что виноват сайт, а не CRM или менеджер
Сравниваю время отправки тестовой заявки с временем её появления в CRM или на почте. Если заявка ушла с сайта по логам сервера, но не появилась в CRM, проблема в интеграции или на стороне CRM. Если заявка вообще не ушла с сайта, значит дело в самой форме или в скрипте на странице.