Наш основной упор сделан на сложные синтетические тесты, включая сценарии на базе Playwright, которые полностью имитируют действия реальных пользователей в браузере.
В процессе написания интеграционных тестов, отладки вебхуков и настройки алертов мы регулярно упираемся в одну и ту же проблему: как быстро, без написания локальных заглушек и костылей, проверить реакцию системы на нетипичное поведение бэкенда?
Чтобы упростить жизнь разработчикам, QA-инженерам и DevOps-специалистам, мы запустили набор бесплатных утилит-песочниц прямо внутри нашей инфраструктуры. Теперь вам не нужно разворачивать сторонние тяжелые сервисы.
Как это работает: Возвращает именно тот HTTP-код ответа, который вы указали в URL.
Примеры использования:
/tools/code/503 — симулирует перегрузку сервера (Service Unavailable). Отличный способ проверить, сработает ли в вашем коде или скрипте мониторинга механизм повторных запросов (retry-логика).
/tools/code/401 — для проверки обработки истекшей сессии или невалидного токена авторизации.
Как это работает: Параметр failure_rate задает вероятность падения эндпоинта. Например, при значении 0.3 ровно 30% запросов гарантированно завершатся ошибкой 502 Bad Gateway, а остальные 70% вернут успешный 200 OK.
Зачем это нужно: С помощью этого эндпоинта можно проверить, насколько ваша система устойчива к периодическим сетевым ошибкам и правильно ли вы настроили фильтрацию шума и интервалы проверок в алертах.
Как это работает: Принимает любые HTTP-методы (GET, POST, PUT, DELETE) и возвращает структурированный JSON со всем, что пришло в запросе: IP-адрес, метод, все HTTP-заголовки, query-параметры и тело.
Зачем это нужно: Самый быстрый способ отладить отправку вебхуков или проверить сложные цепочки авторизации в скриптах Playwright. Вы сразу увидите, в каком формате уходят данные и не режутся ли важные заголовки прокси-серверами по пути.
Как это работает: Задерживает отправку ответа на указанное количество миллисекунд. Максимальный лимит — 60000 (60 секунд).
Зачем это нужно: Часто разработчики забывают явно выставить таймауты на сетевых клиентах, из-за чего в продакшене при долгой отдаче от внешних API зависают и падает всё приложение. Передав /tools/delay/5000, вы можете сымитировать пятисекундную задержку внешней системы и посмотреть, как поведет себя ваш код.
Как это применять в мониторинге Pingera?
Вы можете прямо сейчас встроить эти адреса в свои синтетические тесты и сценарии на Playwright, чтобы эмулировать падение смежных систем, тестировать обработку ошибок интерфейсом или замерять реакцию алертинга на критическую деградацию времени отклика.
Пользуйтесь, тестируйте свои системы на прочность, и пусть ваш аптайм всегда стремится к 100%!