Одного кода ответа 200 часто недостаточно. Если API формально отвечает, но возвращает неверные данные, пустой массив или сломанное поле, это тоже должно считаться проблемой.
Многие сбои не выглядят как классическое падение сервиса. Endpoint может продолжать отвечать, но возвращать некорректное состояние: неправильный флаг, пустой результат, неожиданное значение или частично сломанный объект.
Поэтому мониторинг API должен уметь проверять не только статус ответа и время отклика, но и конкретные поля JSON. Именно это позволяет ловить тихие сбои, которые иначе долго остаются незамеченными.
В UpWatch JSON-проверки работают как отдельный слой поверх HTTP-монитора. Можно проверять ожидаемое содержимое ответа и затем видеть в истории, какая именно проверка не прошла и что отличалось от ожидания.
Начните с API, где важен не только код ответа, но и конкретные данные внутри JSON.
Проверяйте status, healthy, version, count, queue size или другие поля, которые показывают реальное состояние.
Правило должно быть конкретным: какое поле проверяется и какое значение считается нормальным.
При сбое важно видеть не только факт ошибки, но и различие между ожидаемым и фактическим значением.
Когда команда ориентируется только на HTTP 200/500, она пропускает целый класс ошибок. Сервис может отвечать 200, но уже нарушать бизнес-сценарий. Для клиента это реальная проблема, хотя инфраструктурно всё выглядит живым.
JSON-проверки дают более честную модель контроля. Вы смотрите не только на транспортный уровень, но и на содержимое ответа, которое важно именно для вашего продукта.
Это особенно ценно для внутренних API, фоновых интеграций, сервисов с важными флагами состояния и сценариев, где “живой endpoint” ещё не означает “система работает правильно”.
Потому что 200 означает только успешный HTTP-ответ. Данные внутри ответа всё равно могут быть неверными.
Поля, которые отражают здоровье сервиса или бизнес-логику: статус, флаги, количество элементов, версию, состояние очереди.
Да. Это хороший способ поймать тихие ошибки, когда endpoint отвечает, но возвращает неправильные данные.
Базовый сценарий проверки endpoint-ов, методов запроса, заголовков и таймаутов, поверх которого работают JSON-проверки.
Смотрите, какая именно JSON-проверка не прошла, чем expected отличается от actual и как проблема развивалась по запускам.
Посмотрите, как последовательные ошибки JSON-проверок собираются в инцидент и связываются с общей картиной сбоя.
