Status page — канал коммуникации во время инцидентов. Но «коммуникация» с клиентом и «коммуникация» с инженером — два разных процесса. Клиенту нужно: «Checkout недоступен, работаем, ETA 15 минут». Инженеру нужно: «payment-service OOMKilled, pod restarting, DB connections at 98%».
Отсюда два типа status pages — public и internal. Ниже разбираем, что показывать на каждой, кому нужны обе, и как настроить.
Public status page
Аудитория
Клиенты, партнёры, потенциальные покупатели, пресса. Люди, которые не знают (и не должны знать) вашу архитектуру. Им важно: работает ли сервис? Если нет — когда починят?
Что показывать
Компоненты по capability: «API», «Dashboard», «Payments», «Email Notifications» — не «user-service», «payment-service-v2», «kafka-cluster».
Статусы: Operational / Degraded Performance / Partial Outage / Major Outage. Четыре уровня достаточно.
Инциденты: timeline с updates каждые 15-30 минут. Что затронуто, какое влияние, что делается, ETA.
История: uptime за 90 дней. Показывает надёжность для потенциальных клиентов и партнёров.
Подписки: email/webhook notifications при изменениях. Клиент получает update без необходимости обновлять страницу.
Чего НЕ показывать
Внутренние имена сервисов — раскрывают архитектуру.
IP-адреса, hostnames, database names — security risk.
Детальные error messages — «OOMKilled» ничего не скажет клиенту, но может помочь атакующему.
Внутренние метрики — CPU usage, memory, queue depths — это для internal page.
Зачем нужна
Сокращает нагрузку на support: вместо 50 тикетов «сайт не работает?» — клиенты проверяют status page.
Строит доверие: прозрачность в кризисе → лояльность после. Компании со status page воспринимаются как более зрелые.
SLA compliance: uptime история на status page — доказательство для SLA отчётов.
Internal status page
Аудитория
Инженеры, on-call, support, product managers. Люди, которые знают архитектуру и принимают решения во время инцидентов.
Что показывать
Per-service health: статус каждого микросервиса, database, cache, queue. С latency и error rate.
Infrastructure: pod/container status, deployment version, resource utilization.
Dependencies: third-party API status (Stripe, AWS, SendGrid). Их outage может быть причиной вашего.
Active deploys: кто что деплоит прямо сейчас. Недавний deploy — частая причина инцидентов.
Runbook links: прямые ссылки на runbooks для каждого сервиса.
Зачем нужна
Ускоряет triage: on-call инженер открывает internal page и за 30 секунд видит: какой сервис red, какие зависимости affected, что деплоилось. Без неё — 10 минут на открытие 5 dashboards.
Single pane of glass: support видит тот же статус, что инженеры. Не нужно спрашивать «а что сейчас с API?» — всё на одной странице.
Post-incident context: во время post-mortem internal page показывает timeline: что упало первым, что стало cascading effect.
Сравнение
| Критерий | Public | Internal |
|---|---|---|
| Аудитория | Клиенты, партнёры | Инженеры, support |
| Компоненты | По capability (API, Payments) | По service (user-svc, payment-svc) |
| Детализация | High-level status | Latency, error rates, resources |
| Доступ | Public URL | SSO / VPN |
| Incident updates | Customer-friendly | Technical details |
| Subscribers | Email, webhook | Slack, PagerDuty |
| Цель | Доверие и прозрачность | Скорость диагностики |
Кому нужна какая
Только public
Стартапы, SaaS с маленькой командой (1-5 человек), open-source проекты. Все в курсе архитектуры, internal page дублирует Grafana dashboards. Public — для клиентов.
Public + Internal
Растущие команды (5-50 человек), B2B SaaS с SLA, компании с on-call ротациями. Support нужна internal view для ответов клиентам. Инженеры нужен быстрый triage.
Audience-specific pages
Enterprise: отдельная status page для каждого крупного клиента (показывает только их сервисы). Partner-specific pages для интеграционных партнёров. AtomPing поддерживает множественные status pages на одном аккаунте.
Настройка в AtomPing
Public page: создайте status page с компонентами по user-facing capabilities. Привяжите monitors к компонентам. Включите subscriber notifications. Добавьте custom domain (Pro plan): status.yourcompany.com.
Internal page: создайте вторую status page с per-service компонентами. Ограничьте доступ (внутренняя ссылка, не публикуйте). Привяжите технические monitors (health check endpoints).
Автоматизация: monitors привязаны к компонентам. Check fails → component status changes → incident created → status page updated → subscribers notified. Ноль ручных действий для detection.
Связанные материалы
Полное руководство по status pages — от первого компонента до incident communication
Incident Management Guide — как status page вписывается в incident workflow
Incident Communication Templates — что писать на status page во время outage
Status Page Best Practices — компоненты, дизайн, update cadence
FAQ
What is a public status page?
A public status page is a web page accessible to anyone (customers, partners, media) showing real-time status of your services. It displays component health, active incidents, historical uptime, and scheduled maintenance. Examples: status.github.com, status.stripe.com.
What is an internal status page?
An internal status page is only accessible to your team (behind SSO or VPN). It shows more detailed information: individual microservice health, infrastructure metrics, deployment status, and internal dependencies. Used by engineering and support teams for faster incident triage.
Do I need both public and internal status pages?
Most teams benefit from both. The public page communicates with customers (what's affected, when will it be fixed). The internal page helps your team diagnose issues (which service failed, what's the root cause). Without a public page, support gets flooded. Without an internal page, engineers waste time gathering context.
What should I show on a public status page?
User-facing components grouped by capability (API, Dashboard, Payments, Notifications), current status per component, active incidents with updates, uptime history (90 days), and scheduled maintenance. Never expose internal service names, server IPs, or detailed error messages.
Can I use one status page for both public and internal?
Not recommended. Public pages need simplicity and customer-friendly language. Internal pages need technical detail and infrastructure visibility. Mixing them either overwhelms customers with jargon or deprives engineers of useful data. AtomPing supports multiple status pages per account.
How do I handle security concerns with status pages?
Public pages should never reveal architecture details, server names, IP addresses, or vulnerability information. Use customer-facing component names (Payments, not payment-service-v2). For internal pages, use SSO/VPN access control. During security incidents, communicate impact without disclosing attack vectors.