MultigeoMonitoring

Контекст

Мониторинг, который думает географией

MultigeoMonitoring проверяет доступность доменов из множества выбранных стран в реальном времени и шлёт алерты о падениях. Обычный uptime-мониторинг смотрит из одной точки — а реальная доступность зависит от географии, ISP-роутинга и локальных сетей. Я отвечал за продуктовый дизайн: от аналитики и BRD до архитектуры, лендинга и UI-паттернов.

Логика

Incident-first

Ось данных

Страна

Тема

Тёмная · бирюза

Зона

Продукт целиком

Задача

Сделать читаемой плотную матрицу «домены × страны»

Гео-мониторинг порождает плотную матрицу: десятки стран на сотни и тысячи доменов. В лоб это превращается в нечитаемую тепловую карту, которая ломается на масштабе. Нужно было собрать интерфейс, в котором за секунду видно «где плохо», и который не разваливается при 1000 доменов.

Что я сделал

Собрал гео-центричный продукт от аналитики до UI

Incident-first интерфейс: «где плохо», а не «всё хорошо»

Сделал errors-only основным режимом, а не вторичной вкладкой. Продукт открывается на проблемах: сразу видно, какие домены и в каких странах недоступны — интерфейс для реагирования, а не для отчётов.

Страна — сущность первого класса

Перестроил данные вокруг страны как первичной оси: country-токены, ISO-коды, флаги-эмодзи, аккуратные таймзоны и форматы дат. У конкурентов гео — доп. настройка; здесь это ядро модели.

Прогрессивное раскрытие плотной матрицы

Нечитаемую тепловую карту «домены × страны» свернул в трёхуровневую систему с раскрытием по требованию: сверху — только страны с проблемами, глубже — домены внутри страны, ещё глубже — детали конкретной проверки. Так интерфейс не разваливается на масштабе.

Позиционирование

Чем отличается от UptimeRobot, StatusCake и BetterStack

Итог

Сложный гео-домен, собранный в понятный продукт

Из плотной матрицы и «VPN-хаоса» получился читаемый incident-first продукт: гео-центричная модель, прогрессивное раскрытие, заложенная SaaS-готовность и тёмный лендинг под позиционирование.

Дальше