Мониторинг доступности API, POST-запросов и форм на сайте

Зачем нужен мониторинг API, когда сайт открывается

Главная страница открывается, фронтенд и мобильное приложение загружаются, а бэкенд на /api/orders отдаёт 500 — и никто не знает, пока клиент не напишет в поддержку. Обычная проверка сайта такого не увидит: HTML отдаёт nginx из кеша, а ломается именно эндпоинт, к которому обращаются приложение и партнёры.

Второй частый случай — интеграции. Платёжный шлюз, служба доставки или 1С опрашивают ваш API по расписанию; когда он отвечает 401 из-за истёкшего токена или 502 после деплоя, заказы копятся в очереди ошибок. Мониторинг API endpoint с теми же заголовками, что шлют партнёры, показывает проблему через минуту, а не через сутки.

Третий — формы. Форма обратной связи и форма заявки живут на сайте месяцами, но после обновления CMS, смены капчи или SMTP-пароля заявки перестают доходить, а страница по-прежнему отвечает 200. POST-монитор отправляет тестовую заявку и проверяет фразу в ответе.

Что проверяем

• Монитор типа HTTP отправляет к адресу эндпоинта запрос выбранным методом — GET, HEAD или POST — с выбранных [точек](/locations): Москва, Казань, Хельсинки, Мадрид, Милан и партнёрские. Интервал от 1 минуты, таймаут по умолчанию 15 секунд. Точка записывает код ответа, время ответа и тело — по телу проверяются фраза и число.
• Условия «здорового» ответа задаёте вы: ожидаемые коды диапазонами и списками («200-299,301»), порог времени ответа в миллисекундах, фраза, которая должна присутствовать или отсутствовать, минимальный и максимальный размер ответа, число по регулярному выражению с порогами. Не выполнено хотя бы одно условие — точка фиксирует ошибку с причиной: «HTTP 503 вместо 200-299», «фраза "status":"ok" не найдена».
• Сбой подтверждается, когда ошибку видят столько точек, сколько вы указали, — проблема сети между одной точкой и вашим хостингом не становится ложной тревогой. Открывается инцидент с временем начала, подтвердившими точками и причиной; при восстановлении приходит сообщение с длительностью.

Как Нотифарио проверяет доступность API

Монитор типа HTTP отправляет к адресу эндпоинта запрос выбранным методом — GET, HEAD или POST — с выбранных точек: Москва, Казань, Хельсинки, Мадрид, Милан и партнёрские. Интервал от 1 минуты, таймаут по умолчанию 15 секунд. Точка записывает код ответа, время ответа и тело — по телу проверяются фраза и число.

Условия «здорового» ответа задаёте вы: ожидаемые коды диапазонами и списками («200-299,301»), порог времени ответа в миллисекундах, фраза, которая должна присутствовать или отсутствовать, минимальный и максимальный размер ответа, число по регулярному выражению с порогами. Не выполнено хотя бы одно условие — точка фиксирует ошибку с причиной: «HTTP 503 вместо 200-299», «фраза "status":"ok" не найдена».

Сбой подтверждается, когда ошибку видят столько точек, сколько вы указали, — проблема сети между одной точкой и вашим хостингом не становится ложной тревогой. Открывается инцидент с временем начала, подтвердившими точками и причиной; при восстановлении приходит сообщение с длительностью.

Что приходит в уведомлении

🔴 API заказов — не работает
https://api.example.ru/v1/orders

Причина: HTTP 502 вместо 200-299
Начало: 14.09.2026 09:41 (МСК)
Точки: Москва, Хельсинки

Открыть монитор →

Так выглядит сообщение о сбое; о восстановлении придёт отдельное — с длительностью простоя. Каналы: Telegram, MAX, email, SMS, звонок, webhook.

Для мониторинга API с POST-запросом укажите тело и Content-Type: по умолчанию application/x-www-form-urlencoded (login=test&password=test), для JSON API — application/json и тело вида {"query":"ping"}. Так проверяется не «отвечает ли эндпоинт», а обрабатывает ли он настоящий запрос: авторизацию, поиск, расчёт доставки.

Заголовки авторизации добавляются парами «ключ → значение»: Authorization: Bearer <токен>, X-Api-Key, свой User-Agent и Referer. Для эндпоинтов за HTTP Basic Auth есть отдельные поля логина и пароля, они хранятся зашифрованными. Монитор с заголовками, телом запроса или Basic Auth выполняется только с точек notifar.io — партнёрские точки такие задания не получают. Ключ лучше передавать в заголовке, а не в адресе: адрес виден в логах вашего сервера и прокси. Если API закрыт WAF, IP-адреса точек для белого списка выдают по запросу в поддержку.

Отдельно настраиваются редиректы: следовать им или нет и какой конечный адрес ожидать, чтобы редирект на страницу входа не считался успешным ответом. Перед настройкой посмотрите, что эндпоинт отдаёт сейчас: проверка с точек и заголовки ответа и редиректы работают без регистрации.

API часто «жив» по коду, но отдаёт мусор: 200 с {"error":"db connection failed"} или пустой массив вместо каталога. Поэтому проверяйте и тело. Фраза «должна присутствовать» — "status":"ok" в health-эндпоинте; «должна отсутствовать» — "error" или «Ошибка базы данных». Оба условия можно задать одновременно.

Число в ответе извлекается регулярным выражением с группой и сравнивается с порогами: «"items_total":(\d+)» → не меньше 1 — каталог не опустел; «"queue":(\d+)» → не больше 500 — очередь не растёт.

Ожидаемые коды: «200-299» для обычного эндпоинта, «401» для контроля, что закрытый метод не открылся наружу, «200,204» для методов без тела. Порог времени ответа превращает деградацию в инцидент до того, как API упадёт совсем: ответ дольше 2 000 мс с двух точек — уведомление.

Форма обратной связи — тот же POST: монитор отправляет поля формы (name=Тест&phone=79990000000&message=проверка) на адрес обработчика с Content-Type application/x-www-form-urlencoded и ждёт фразу «Спасибо, заявка принята» или ожидаемый конечный адрес — страницу «Спасибо» после редиректа. Стал обработчик после обновления CMS отдавать 500, «Ошибка отправки» или пустую страницу — придёт уведомление.

Чтобы тестовые заявки не мешали менеджерам, добавьте в тело поле-метку (source=notifar) и отфильтруйте её в CRM. Интервала 15 минут для формы обычно достаточно: 96 проверок в сутки с одной точки по 0,01 ₽ — около 29 ₽ в месяц.

Формы за капчей или с одноразовым CSRF-токеном так не проверить — токен меняется на каждую загрузку. Проверяйте обработчик отдельным тестовым маршрутом без капчи или контролируйте, что страница с формой отвечает и содержит нужные поля. Для интернет-магазина тот же приём применяется к оформлению заказа и платёжной странице.

Когда сбой подтверждён, сообщение уходит в Telegram и MAX, на email, по SMS за 7 ₽ или звонком за 15 ₽ — робот озвучит название монитора и причину. В сообщении — адрес, причина («HTTP 502 вместо 200-299», «фраза не найдена»), время начала и подтвердившие точки; при восстановлении — длительность.

Для реакции без человека есть исходящий webhook: POST JSON с подписью HMAC на ваш адрес при событиях down и up — на него вешают перезапуск сервиса или создание тикета. Тихие часы, пауза и окна обслуживания на время деплоя не дают плановым работам будить команду.

Состояние API можно показать клиентам и партнёрам на публичной статус-странице с uptime за 90 дней и историей инцидентов. Цена — от 0,01 ₽ за проверку, без абонплаты и лимита на число мониторов.

Параметры проверки

Интервал — от 1 минута до 1 суток (рекомендуем 5 минут). Проверка выполняется с выбранных точек мониторинга, сбой подтверждается заданным числом точек.

Чем это лучше curl в cron на своём сервере

• Проверка идёт снаружи, из сетей в России и Европе: скрипт на том же сервере не заметит, что упал сервер, канал провайдера или DNS.
• Подтверждение сбоя с нескольких точек — одна плохая маршрутизация не будит команду в три часа ночи.
• Каналы уже готовы: Telegram, MAX, SMS, звонок, email, webhook с подписью, тихие часы, повторы и уведомление о восстановлении.
• История ответов, график времени ответа по точкам, инциденты с длительностью и uptime за 7/30/90 дней — без своей базы и дашборда.

Вопросы