Максим Дорохов 
Чек-лист мониторинга для SaaS-сервиса: что настроить в первую очередь
Для интернет-магазина простой — это упущенные заказы за конкретный час. Для SaaS всё жёстче: недоступное приложение или сломанный вход — это одновременно все клиенты сразу, и часть из них имеет полное право написать в поддержку с вопросом про SLA. Разбираем, что настроить в первую очередь.
Доступность приложения и лендинга — отдельно
Маркетинговый сайт и само приложение (app.вашдомен) часто живут на разной инфраструктуре и могут падать независимо друг от друга. Если проверять только лендинг, сбой в самом приложении — там, где клиенты реально работают, — можно не заметить вовсе, хотя это как раз критичнее с точки зрения бизнеса.
Страница входа и ключевые API-эндпоинты
Страница логина. Если она недоступна или отдаёт ошибку, все клиенты одновременно теряют доступ к продукту — это один из самых дорогих типов простоя, который стоит проверять чаще, чем второстепенные страницы.
Критичные API-эндпоинты. Для SaaS API часто и есть продукт — если через него работают интеграции клиентов, его недоступность бьёт не только по интерфейсу, но и по чужим автоматизированным процессам, завязанным на ваш сервис.
SSL-сертификат — критичнее, чем кажется
Истёкший сертификат для SaaS — это не просто предупреждение браузера, которое кто-то не заметит. Многие интеграции клиентов (webhooks, API-клиенты, серверные запросы) без человека в цепочке просто откажутся соединяться с невалидным сертификатом — тихий сбой у всех интеграций разом, часто до того, как это заметит хоть один живой пользователь через браузер.
Внешний мониторинг проверяет, что страница или эндпоинт отвечает и возвращает ожидаемый код или контент — это не то же самое, что полноценный синтетический тест реального сценария входа с логином и паролем. Для критичных путей вроде оплаты или онбординга стоит дополнительно держать отдельный процесс ручного или автоматизированного end-to-end тестирования — мониторинг доступности его не заменяет, а дополняет.
Эскалация для дежурного, а не только уведомление в чат
Для B2B SaaS с оплатой за доступность стоит настраивать не единый канал на всех, а разделение: дежурный инженер получает всё немедленно и по самому надёжному каналу, руководитель — только продолжительные инциденты, общий чат команды — уведомление о восстановлении. Без такого разделения либо все игнорируют поток, либо никто конкретно не чувствует ответственности среагировать первым.
В Пруфене можно отдельно настроить проверку доступности для лендинга, приложения и ключевых API-эндпоинтов с разными интервалами, а проверка SSL-сертификата предупредит об истечении заранее, до того как это затронет интеграции клиентов.
Частые вопросы
Чем этот чек-лист отличается от чек-листа для интернет-магазина? У магазина в фокусе товарные фиды и статус заказа, у SaaS — непрерывность API и авторизации: там, где для магазина критична витрина, для SaaS критична сама возможность клиента залогиниться и продолжить работать.
Нужно ли проверять именно страницу логина, а не общую доступность домена? Да — домен может формально отвечать 200, пока форма входа сама по себе сломана из-за фронтенд-бага. Это разные точки отказа, и стоит проверять именно ту, что реально важна для клиента.
С какого интервала начинать для критичных эндпоинтов? Минимальный доступный интервал разумен для страницы логина и ключевых API — цена короткого простоя здесь обычно выше стоимости самой частой проверки.
Мониторинг доступности заменяет полноценный синтетический тест сценария? Нет — он подтверждает, что эндпоинт или страница отвечают корректно, но не эмулирует реальный ввод логина и пароля пользователем. Для этого нужен отдельный инструмент end-to-end тестирования.