Привет! Меня зовут Михаил Шпаков, я разрабатываю Statuser — платформу для мониторинга доступности сайтов, приложений и серверов. Делаю всё один, по вечерам, без команды.

В этой статье я расскажу, как появилась функциональность, которая была в планах с самого начала — публичные страницы статуса. Эта идея зрела давно, и запросы от первых клиентов только ускорили её появление.

Объясню, как всё устроено внутри, с какими техническими решениями пришлось столкнуться и почему статус-пейджи — это логичное продолжение любого хорошего мониторинга.

Если хотите сразу посмотреть, как это выглядит — вот пример публичной страницы статуса. Она собирается на основе реальных проверок, с инцидентами, графиком аптайма и кастомизацией.

В прошлой статье я описал, как вообще появился Statuser, с какими проблемами столкнулся и зачем всё это затеял. Если пропустили — вот ссылка:

Как я по вечерам разрабатывал Statuser — платформу для мониторинга доступности приложений

❯ Когда мониторинга мало

Мониторинг даёт сигнал, когда что-то пошло не так. Он фиксирует ошибку, отправляет уведомление, пишет в лог и рисует красную точку на графике. Но что делать с этим дальше — мониторинг не подсказывает.

Если у вас что-то упало, пользователи не заходят в Grafana. Они идут в Telegram, в поддержку, в чат с аккаунт-менеджером — и спрашивают: «Что происходит?», «Когда всё починят?», «Это только у нас или у всех?»

Вот это — настоящая точка боли. Мониторинг фиксирует факт, а люди ждут объяснений. Ждут, что им честно покажут: «да, сейчас проблема, да, мы в курсе, да, вот прогресс».

Крупные команды в этот момент часто попадают в ловушку:

• Поддержка начинает отвечать руками — «да, упало», «да, скоро поднимем».

• Менеджеры скидывают скриншоты графиков или руками пересказывают статусы.

• Пользователи не знают, где посмотреть информацию и пишут всем подряд.

• А инженеры тем временем просто чинят проблему — и отвлекаться им нельзя.

У одного из клиентов Statuser была ровно такая ситуация: упал один из микросервисов, цепочка зависимостей привела к массовым 500-кам на фронте. Мониторинг сработал, алерты пришли, но… начался поток писем от клиентов. Хотя технически всё было под контролем — ощущения «контроля» у пользователей не было совсем.

Тогда стало очевидно: одного мониторинга мало. Нужен способ спокойно, красиво и честно показать пользователям, что происходит — и что всё под контролем.

❯ Встроенные статус-пейджи как часть мониторинга

Сейчас статус-пейджи в Statuser — это полноценный инструмент, которым может пользоваться любой клиент. Всё, что уже есть в системе (проверки, инциденты, аптайм), автоматически ложится в основу страницы. Дальше остаётся только настроить её под себя.

Что умеет статус-страница:

• Размещение на общем или собственном домене
  По умолчанию можно опубликовать страницу на up.statuser.cloud с любым удобным slug’ом. Подключение кастомного домена — тоже предусмотрено, через отдельную вкладку и настройку CNAME DNS-записи.

• Кастомизация внешнего вида
  Можно загрузить логотип и фавикон, указать ссылку на сайт компании и емейл для обратной связи. Есть и white label-режим — без логотипа Statuser. Сейчас он отключен, но появится в платной версии.

• Гибкие настройки приватности
  По умолчанию страница доступна по прямой ссылке. Можно разрешить индексацию поисковиками или наоборот — сделать её приватной. Также доступна защита паролем для внутренних страниц.

• Несколько страниц для разных задач
  Statuser позволяет создать не одну, а сразу несколько статус-страниц — например, отдельную для клиентов, партнёров или внутреннего использования.

Всё это — часть платформы, не требующая дополнительных интеграций или ручного обновления. Инциденты подгружаются автоматически, аптайм считается на основе проверок, статус серверов меняется сам.

При этом я стараюсь делать не просто «чтобы работало», а чтобы было удобно. Например, в настройке страницы можно легко менять порядок групп и серверов внутри них с помощью drag-and-drop — просто перетащить мышкой, как в Notion или Trello. Это кажется мелочью, но такие штуки сильно улучшают повседневный опыт.

❯ Как всё устроено внутри

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

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

Кастомные домены

Один из важных вопросов — поддержка собственных доменов. Я решил отдать эту задачу Caddy: он прост в настройке, работает через REST API и сам выпускает сертификаты через Let’s Encrypt, что сильно упрощает жизнь. Он запускается в отдельном Docker-контейнере на выделенной машине, конфиг хранится на диске и ежедневно бэкапится в S3.

Когда клиент подключает собственный домен, Statuser:

1. проверяет, правильно ли настроена CNAME-запись в DNS (это происходит в фоне и повторяется до успешного результата),

2. как только запись появляется — автоматически отправляется запрос в API Caddy, и тот настраивает маршрут и выпускает сертификат.

Пользователь просто добавляет запись — всё остальное происходит автоматически: домен начинает работать с HTTPS без лишних шагов и ожидания.

Роутинг, SEO и производительность

Публичные страницы отдаются через Next.js, который обрабатывает:

• маршруты на общем домене (up.statuser.cloud/s/slug) и кастомных доменах (через заголовки от Caddy),

• генерацию robots.txt и sitemap.xml на лету,

• рендеринг с учётом контента, связанного со статусом и инцидентами.

Вся статика — логотипы, фавиконы, иконки — хранится на S3 и оттуда же отдаются.

Чтобы страницы работали быстро и стабильно, я опираюсь на инциденты, которые уже прошли проверку на достоверность:

Инцидент создаётся только если все локации зафиксировали недоступность сервиса. Это даёт уверенность, что на статус-пейдже отображаются только реальные проблемы, а не разовые сбои в одной точке.

Это снижает нагрузку и делает страницу полностью автономной — она не зависит от скорости или периодичности проверок.

Учет таймзоны

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

❯ Что дальше

После запуска статус-пейджей стало понятно, что у клиентов на этот счёт много идей. Кто-то сразу начал использовать страницы публично, кто-то — внутри команды, а кто-то просто написал: «А будет вот это? Нам бы пригодилось».

Ниже — три фичи, которые чаще всего всплывали в переписке с клиентами. Именно их я планирую сделать в первую очередь.

Публичные отчёты об инцидентах

Частый запрос — описание самого инцидента. Сейчас он просто фиксируется и отображается на странице. Но клиенты хотят большего: указать промежуточные статусы (например: идёт расследование, обнаружена причина, исправлено) и добавить финальный постмортем. Это нужно тем, кто публично отвечает за стабильность продукта — будь то заказчики, пользователи или просто команда, которая хочет быть честной и понятной в коммуникации.

Плановые технические работы

Ещё один сценарий — возможность анонсировать заранее запланированные технические работы. Чтобы указать, когда и почему будет временная недоступность, и не отвечать на вопросы в момент «почему всё красное». Такие события не будут учитываться в аптайме и будут отображаться на странице отдельно.

Подписка на уведомления

И наконец — подписка на страницу. Чтобы пользователь сам оставил емейл, и больше не спрашивал: «А что с сервисом?». Сейчас всё это на плечах клиента — хочу сделать так, чтобы система сама отправляла письма о сбоях, восстановлении и промежуточных обновлениях.

Все эти штуки уже лежат в бэклоге, часть — в работе. Как и всё в Statuser, это не просто roadmap «на всякий случай», а логичное продолжение того, что уже есть и что просят живые люди.

Если у вас тоже есть идеи — пишите. Я всё читаю, всё собираю, и потихоньку превращаю в код.

❯ Вместо вывода

Мониторинг — это про то, чтобы быстро узнать, что что-то пошло не так.

Страница статуса — про то, чтобы не прятаться, когда это случилось.

Это две стороны одной задачи. Первая — техническая. Вторая — человеческая.

А цель у них общая — доверие.

Если вы ещё не пробовали статус-пейджи в Statuser — попробуйте. Всё настраивается просто: выбрали сервера, указали домен — и страница готова.

? statuser.cloud

? Демо страница статуса

Спасибо, что дочитали до конца. Если статья оказалась полезной или просто отозвалась — буду рад вашей обратной связи в комментариях.

А если чего-то не хватает — дайте знать. Возможно, именно это станет следующим пунктом в моём бэклоге.

Если хочется обсудить что-то лично — пишите в Телеграм: @mshpakov.

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩