Плановый мониторинг в PolyApiIDE: автопроверка запросов по расписанию

Я делаю PolyApiIDE, и один из вопросов, который звучит регулярно: «а можно, чтобы это само проверялось, пока я не смотрю?». Да, можно — это называется Scheduled Monitoring (плановый мониторинг). В этой статье — что это конкретно делает, как это настроить, и, что важнее, какие у этого есть реальные границы, которые я не хочу прятать.

Что это такое

Scheduled Monitoring берёт сохранённый запрос, коллекцию или QA-сценарий и перезапускает его автоматически на таймере — без того, чтобы вы держали открытой вкладку IDE и смотрели на неё. Минимальный интервал — 5 минут; чаще поставить нельзя, и это осознанное ограничение, а не временная недоработка.

Идея простая: вместо того чтобы вручную гонять один и тот же запрос каждые N минут, проверяя «всё ещё работает?», вы один раз настраиваете проверку и дальше просто смотрите на результат, когда вам удобно — или получаете алерт, когда что-то пошло не так.

Как настроить проверку

Концептуально это три шага:

• выбрать, что проверять — конкретный сохранённый запрос, целую коллекцию или QA-сценарий с ветвлением;
• задать интервал — от 5 минут и выше, в зависимости от того, как часто вам реально нужна проверка;
• указать, куда должен прийти алерт при падении (или при каждом прогоне, если так настроено) — в мессенджер, на endpoint Pushgateway или на собственный webhook URL. Все три варианта поддерживаются.

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

Где смотреть результаты

Каждый прогон планового мониторинга попадает в историю/журнал событий внутри расширения — то есть это не «тихая» фоновая задача, результат которой нигде не виден. Упавший плановый прогон отображается в журнале как падение, а не теряется. Алерт — это дополнительный канал уведомления сверху, а не единственное место, где можно узнать, что произошло.

Честное ограничение: только Chrome

Scheduled Monitoring работает только в Chrome-сборке PolyApiIDE. В Firefox-сборке этой функции нет — и не будет в текущем виде, потому что у Firefox отсутствует механизм постоянного фонового выполнения (persistent background execution context), на котором эта функция построена в Chrome. Это не «скоро добавим», это ограничение платформы на сегодняшний день, и я не хочу обещать сроки, которых у меня нет.

Второй момент, который стоит понимать заранее: проверка выполняется внутри самого расширения Chrome, а значит Chrome должен быть запущен — пусть даже свёрнутым или в фоне — чтобы проверки срабатывали. Это не отдельный серверный сервис uptime-мониторинга наподобие Pingdom или UptimeRobot, который работает независимо от вашего компьютера. Если Chrome закрыт или компьютер выключен, проверка не выполнится. Это слой удобства — «мой сохранённый запрос/коллекция всё ещё отвечает как надо, и я узнаю, если нет», — а не инфраструктурный мониторинг уровня эксплуатации.

Лимиты: Free и платные планы

На Free этого достаточно, чтобы понять, нужна ли вам эта функция вообще, прежде чем платить. Если вам нужно следить за несколькими эндпоинтами или сценариями одновременно, платные планы дают до десяти активных проверок параллельно.

Для чего это реально годится

Это удобно как канарейка на staging- или внутреннем API, за которым вы следите во время активной разработки; как сценарий, который должен продолжать проходить, пока вы меняете backend рядом; как периодический smoke-тест для интеграции, которую вы поддерживаете. Это не замена выделенным инструментам ops/SRE-мониторинга — туда, где нужна инфраструктурная надёжность независимо от вашей машины, идите за специализированным решением. Scheduled Monitoring — это «проверить, что мой сохранённый запрос всё ещё работает, автоматически», а не SLA-мониторинг продакшена.

Если вы ещё не настраивали расширение — начните с быстрого старта. Частые вопросы по лимитам планов и платформам — в FAQ.