Components страницы статуса: имена, которые понимают клиенты

Страницу статуса читают клиенты в стрессе — не ваша SRE-команда. Подписи postgres-primary или k8s-deployment-api точны внутри и непонятны снаружи.

StillOnline группирует проверки в components, которые вы задаёте в панели. Посетители видят их на stillonline.tech/s/demo вместе с историей проб и инцидентами. Ниже — карта имён для indie SaaS.

Краткий ответ

Называйте components StillOnline так, как клиенты пользуются продуктом — Панель, API, Платежи, Почта — а не серверами и БД. Держите 3–5 components; на Pro привяжите HTTP-проверки, на Free (один URL на проект) объедините сигналы в /health. При одной проверке страница показывает общий статус; делите components при втором URL на Pro ($9/мес). Публичная страница.

Infra vs язык продукта

SRE от Google — в коммуникации с пользователями описывайте симптомы, не внутренние имена.

Примеры по типу продукта

API-first B2B

Приложение + биллинг

Пример имён у вендоров — Stripe Status: Payments, Dashboard, API, не hostname БД.

Настройка StillOnline

1. Приложение → проект → имена components.
2. Привязка HTTP-проверок (Pro: до 10 на проект).
3. Free: одна проверка — тарифы.
4. Инциденты на нужный component — Degraded vs outage.

FAQ

Зеркалить имена Kubernetes на публичной странице?

Не стоит — клиенты не знают layout кластера.

StillOnline сам создаёт components из проверок?

Имена задаёте вы — согласуйте до первого инцидента — шаблон.

Free, один URL — несколько components?

Да для ручных инцидентов; автоматический статус — одна HTTP-проверка до Pro.