Как выглядит хорошая публичная страница статуса

Публичная страница статуса - это место, куда клиенты идут во время сбоя. Хорошая страница статуса снижает количество тикетов в поддержку и укрепляет доверие. Из чего она состоит.

Что должно быть на хорошей странице статуса

Текущее состояние каждого ключевого сервиса. Не просто "всё OK", а с разбивкой по компонентам (API, web, dashboard, emailing, payment processing).
История инцидентов за последние 90 дней. Без попыток что-либо скрыть - прозрачная история укрепляет доверие.
Метрика uptime (обычно за 30 дней) для каждого компонента, выраженная прозрачным процентом.
Плановое обслуживание. Баннер с датой и описанием того, что будет недоступно.
Активный инцидент с временной шкалой обновлений. Investigating → Identified → Monitoring → Resolved.
Форма подписки. Клиенты получают письмо при изменении статуса и им не нужно повторно проверять страницу.

Чёткая иерархия компонентов

Вместо единственной записи "monitor" разбейте сервис на компоненты, которые имеют смысл с точки зрения клиента:

Web App - frontend (им пользуются посетители)
API - backend для программных интеграций
Auth / Login - вход в систему
Email delivery - транзакционные письма
Background jobs - sync, биллинг, экспорты
Status page - мета-компонент: сама страница статуса тоже может упасть (поэтому она должна работать на другой инфраструктуре, чем продукт)

Incident communication: анатомия хорошего обновления

При реальном сбое соблюдайте эти фазы:

Investigating - "Мы выявили проблему с [компонент]. Команда выясняет причину." (в течение 5 мин с момента обнаружения)
Identified - "Причина - [кратко]. Работаем над исправлением. ETA [время]." (когда вы знаете, что вызывает проблему)
Monitoring - "Мы развернули исправление. Наблюдаем, не повторится ли проблема." (после развёртывания решения)
Resolved - "Инцидент устранён. Длительность X минут. Далее последует postmortem." (после подтверждённого восстановления)

Каждая фаза получает timestamp и собственное обновление. После инцидента опубликуйте post-mortem (root cause, timeline и меры, предотвращающие повторение).

Правило: Никогда не используйте расплывчатые фразы вроде "experiencing some issues". Клиенты хотят конкретики: "Вход не удаётся в ~30 % попыток. API работает нормально. Веб доступен только в режиме read-only."

Hosting: принцип независимой инфраструктуры

Страница статуса должна работать на другой инфраструктуре, чем мониторируемый сервис. Если у вас падает регион AWS, страница статуса, размещённая в том же регионе, падает вместе с ним - ровно в тот момент, когда она клиентам нужнее всего.

Практические решения:

Хостинг через внешний SaaS (ePulz.io, Better Stack, Atlassian Statuspage)
Собственная статическая страница на CDN (Cloudflare Pages, Netlify) с API-эндпоинтом в другом месте
В крайнем случае - минимальная статическая страница на Cloudflare с вручную обновляемым текстом

Subscribers: email и webhook

Клиенты не хотят постоянно обновлять страницу статуса. Поэтому хорошая страница поддерживает:

Email subscribers - в ePulz.io доступно для авторизованных пользователей с платным планом (подписки мы собираем только с подтверждённых аккаунтов, а не с анонимных посетителей)
Webhook - для команд, которые хотят интегрировать статус в собственный Slack или PagerDuty

Anti-pattern: сокрытие проблем

Соблазн пометить сбой как "degraded" вместо "down" (или не показывать его вовсе) велик, но недальновиден:

Клиенты всё равно заметят сбой (через собственный мониторинг, тикеты в поддержку или соцсети)
Вы теряете доверие, когда они обнаруживают, что статус показывает "OK" во время очевидного сбоя
Вы теряете реальную картину тренда uptime, которая нужна вам для внутренних решений

Лучшая стратегия - радикальная прозрачность. GitLab, Cloudflare и Stripe публикуют подробные post-mortem даже при неловких ошибках, и сообщество это ценит.

SEO и бренд

Страница статуса должна:

Находиться на стабильном и легко запоминающемся URL для статуса сервиса
Иметь собственный брендинг (логотип, цвета) - клиент должен видеть, что он всё ещё на вашей странице
Быть проиндексированной в Google (лучшая видимость при поиске "[бренд] down")
Быть прилинкована с главной страницы (футер "Статус сервиса")

Заключение

Страница статуса - это не декорация. Это операционный инструмент, который во время инцидента снижает нагрузку на поддержку и укрепляет долгосрочное доверие. Несколько часов, вложенных в правильную настройку, окупаются сразу при первом крупном сбое.

Создайте страницу статуса за 5 минут

Страницы статуса ePulz.io с собственным брендингом, email subscribers и incident timeline. 7 дней бесплатно.

Попробовать ePulz.io →