Команда Пруфена 
Кейс: форма заказа тихо сломалась — что мониторинг видит, а что нет
После фронтенд-релиза кнопка «Заказать» осталась на месте, страница открывалась штатно, код ответа был 200 — а нажатие на кнопку ничего не делало из-за сломанного JS-обработчика. Реклама продолжала крутиться, трафик шёл на страницу как обычно, и три дня никто не понимал, почему заявки перестали приходить.
Почему это не поймала бы обычная проверка доступности
Проверка доступности отвечает на вопрос «сервер вообще отвечает и возвращает корректный код». В этой ситуации сервер отвечал безупречно — страница отдавалась с кодом 200, весь HTML, вся вёрстка, кнопка присутствовала визуально. С точки зрения такой проверки всё было в полном порядке. Проблема была не в том, что страница не работала, а в том, что не работало действие на ней — а это принципиально другой уровень наблюдения.
Что мог бы поймать более узкий контроль
Если бы на странице была настроена проверка наличия конкретного элемента — например, тревога срабатывает, если на странице появляется определённый класс ошибки, который JS выводит при неудачной попытке отправки, — это можно было бы отследить раньше. Или наоборот: если после отправки заказа пользователь должен попадать на отдельную страницу подтверждения с конкретным текстом, а проверка следит за тем, что эта страница вообще продолжает генерироваться штатным потоком заказов, — резкое обнуление таких подтверждений тоже стало бы заметным сигналом.
Но и это не решает задачу целиком — важно понимать честно
Здесь нужна прямая оговорка: ни один из этих приёмов не проверяет главное — действительно ли заявка дошла до CRM, менеджера или почты. Внешний мониторинг вроде Пруфена работает по HTTP: он умеет проверять, что страница отвечает, что на ней присутствует или отсутствует конкретный элемент, но не умеет заполнять форму значениями, нажимать кнопку отправки и убеждаться, что письмо реально дошло получателю. Это уже задача синтетического end-to-end тестирования конкретного сценария или мониторинга на стороне самой CRM — другой класс инструментов, не совпадающий с проверкой доступности и контента.
Дашборд мониторинга, полностью зелёный по всем настроенным проверкам, означает ровно то, что проверялось, — и ничего сверх этого. Если критичный сценарий вроде отправки заказа не покрыт ни одной проверкой, его поломка останется невидимой сколько угодно долго, при том что все настроенные метрики будут показывать полный порядок.
Что стоит делать на практике
Разумный минимум — покрыть проверкой контента то, что физически можно отследить снаружи: наличие кнопки и формы на странице, появление явных признаков ошибки в интерфейсе, доступность страницы подтверждения заказа. Это не гарантия, что заявка дойдёт, но это заметно сужает слепую зону и ловит именно тот класс поломок, где страница выглядит нормально, а функциональность на ней тихо отказала.
Пруфен может следить за появлением признаков ошибки на странице заказа и за базовой доступностью самой страницы — но честно: это не проверка того, что заявка дошла до вас. Такую границу стоит держать в голове при построении полной картины контроля критичных страниц.
Частые вопросы
Значит ли это, что мониторинг доступности бесполезен для формы заказа? Нет — он ловит часть проблем (страница упала, появилась явная ошибка в интерфейсе), просто не весь спектр. Частичное покрытие лучше отсутствия любого контроля вовсе.
Как тогда проверять, что заявки реально доходят? Обычно это отдельный процесс: периодическая ручная тестовая заявка, синтетический сценарий в специализированном инструменте или мониторинг на стороне самой CRM/почты, куда должны приходить заявки.
Стоит ли вообще тратить время на контент-проверку формы, если она не даёт полной гарантии? Да — она дешёвая в настройке и ловит реальный, часто встречающийся класс поломок (визуальные ошибки, пропавшие элементы), даже если не закрывает вопрос целиком.
Как часто случаются именно такие «тихие» поломки? Чаще, чем кажется, — любой релиз фронтенда, затрагивающий обработчики форм, потенциально может внести такую регрессию незаметно для команды, если её не поймал явный тест.