Большинство status pages бесполезны. "All Systems Operational" — крупным зелёным текстом, пока в Twitter десятки жалоб "ваш API лежит уже 20 минут". Или наоборот: жёлтый индикатор "Degraded Performance" без объяснения, что именно деградировало, кого это затрагивает и когда починят.
Status page — не декорация и не compliance checkbox. Это инструмент коммуникации с пользователями в самый напряжённый момент: когда что-то сломалось. Ниже — конкретные принципы, по которым лучшие status pages работают как доверительный канал, а не как отписка.
Компонентная структура: что показывать
Первая ошибка — показывать один общий статус: "Operational" или "Down". Пользователю не нужен усреднённый индикатор. Ему нужно знать: "Я не могу загрузить файл — это я или вы?". Ответ даёт компонентная структура.
Принцип: компоненты = пользовательские сценарии
Не дробите по внутренней архитектуре ("Redis Cluster", "Worker Pool B", "PostgreSQL Primary"). Дробите по тому, что видит пользователь:
Для SaaS: Dashboard, API, Authentication, File Upload, Search, Notifications, Billing
Для e-commerce: Website, Catalog, Cart & Checkout, Payments, Order Tracking, Support Chat
Для коммуникационного сервиса: Messaging, Voice Calls, File Sharing, Integrations, Mobile Push
Для инфраструктурного сервиса: API, Dashboard, Webhooks + отдельные строки по регионам (US, EU, APAC)
Оптимальное количество: 5-15 компонентов. Меньше 5 — слишком грубо (не видно, что именно сломалось). Больше 15 — информационный перегруз (пользователь не будет искать свой компонент в списке из 40).
Статусы: не больше четырёх
Operational — всё работает в нормальном режиме.
Degraded Performance — сервис работает, но медленнее обычного или с ограниченной функциональностью.
Partial Outage — часть пользователей или функций затронута. Например: API работает, но загрузка файлов — нет.
Major Outage — сервис недоступен для большинства пользователей.
Не добавляйте промежуточные статусы вроде "Under Maintenance", "Investigating", "Monitoring". Это статусы инцидента, а не компонента. Компонент — либо работает, либо деградирован, либо не работает.
Incident communication: как писать обновления
Текст incident updates — самая важная часть status page. Компоненты и индикаторы — это структура. Updates — это содержание. Именно по ним пользователь решает: "Нужно ли мне звонить в поддержку?" и "Стоит ли искать альтернативу?".
Формула хорошего update
Каждое обновление должно отвечать на три вопроса: Что происходит? Кого это затрагивает? Что вы делаете?
Плохо: "We are investigating an issue with our services."
Хорошо: "We are seeing increased error rates on the Payments API affecting approximately 15% of transactions in the EU region. Credit card payments may fail or take longer than usual. Our engineering team has identified the root cause (database connection pool exhaustion) and is deploying a fix. ETA: 20 minutes."
Разница: второй вариант сообщает что затронуто (Payments API, EU, ~15% транзакций), какое пользовательское воздействие (платежи могут не пройти), причину (connection pool), план (деплой фикса), время (20 минут). Пользователь может принять решение: подождать 20 минут или переключиться на fallback.
Стадии инцидента
Стандартная последовательность, которую пользователи привыкли видеть:
Investigating. "We are aware of the issue and investigating." Первое обновление — максимально быстро. Даже если вы ещё ничего не знаете, "мы знаем и разбираемся" уже снижает тревогу.
Identified. "We have identified the root cause: [description]. A fix is being prepared." Пользователь понимает, что дело движется.
Monitoring. "A fix has been deployed. We are monitoring for stability." Фикс применён, но вы ещё наблюдаете. Не закрывайте инцидент сразу после деплоя — дайте 15-30 минут на подтверждение.
Resolved. "The issue has been fully resolved. All services are operating normally." Включите краткий summary: что случилось, сколько длилось, сколько пользователей затронуло.
Каденция обновлений
Правило: не больше 20 минут между обновлениями во время активного инцидента. Если нечего сказать — скажите это: "Continuing to investigate. No additional information at this time. Next update in 15 minutes." Тишина на status page при активном инциденте — худший сигнал. Пользователь начинает думать: "Они вообще в курсе?"
Автоматизация vs ручное управление
Идеальная status page — гибрид. Мониторинг автоматически обновляет статус компонентов на основе проверок: если HTTP check фиксирует downtime из нескольких регионов — компонент переходит в "Outage" без ручного вмешательства. Но текстовые updates пишет человек.
Почему автоматика не может писать incident updates: потому что "API returns 503" — технический факт, а "Approximately 30% of users in the EU region may experience errors when loading their dashboard" — коммуникация с контекстом и масштабом. Первое — для внутреннего мониторинга. Второе — для status page.
Автоматизировать: обнаружение инцидента, изменение статуса компонента, уведомление подписчикам о новом инциденте, закрытие инцидента после recovery.
Делать вручную: текст incident updates, оценка масштаба воздействия, ETA, пост-мортем.
Отдельная инфраструктура: не кладите status page вместе с продуктом
Status page, которая лежит вместе с основным продуктом — хуже, чем отсутствие status page. Пользователь в момент кризиса пытается проверить статус, получает ту же ошибку и паникует вдвойне.
Решение: отдельный домен (status.yourcompany.com), отдельный хостинг, минимум зависимостей. AtomPing status pages работают на выделенной edge-инфраструктуре, полностью независимой от вашего основного сервиса. Кастомный домен с автоматическим SSL через On-Demand TLS — status page доступна, даже если ваш основной хостинг полностью лёг.
Метрики: uptime и response time
Лучшие status pages показывают не только текущий статус, но и историческую производительность. Это добавляет контекст: "Компонент сейчас в Outage" — плохо, но "Компонент с uptime 99.98% за 90 дней, сейчас первый инцидент за месяц" — другой уровень доверия.
Что стоит показывать:
Uptime за 30/90 дней. Процент доступности за скользящий период. 99.95% за 90 дней = менее 65 минут суммарного downtime.
Response time график. Среднее время ответа за последние 24 часа / 7 дней. Показывает тренд: деградация видна до того, как станет инцидентом.
Incident timeline. Хронология инцидентов за 90 дней. Тепловая карта (как у GitHub) или простой список с датами и продолжительностью.
Post-incident: разбор после инцидента
После серьёзных инцидентов (Major Outage длительностью > 30 минут) публикуйте post-mortem на status page или в блоге с ссылкой из status page. Это не слабость — это самый мощный сигнал доверия.
Структура post-mortem для публичного потребления:
Summary. Что случилось, в одном предложении.
Impact. Кого затронуло, как долго, какие функции были недоступны.
Timeline. Хронология: обнаружение → диагностика → фикс → восстановление.
Root cause. Техническая причина на понятном языке. "Database migration locked a critical table for 12 minutes during peak traffic" — понятно. "Lock contention in pg_class triggered cascading OOM" — только для инженеров.
What we're doing about it. Конкретные шаги, чтобы это не повторилось. "We're adding automated migration impact analysis to our CI pipeline" — убедительно. "We'll be more careful" — нет.
Типичные ошибки
"All Operational" при реальных проблемах. Ничто не подрывает доверие быстрее, чем зелёная status page при массовых жалобах в соцсетях. Если мониторинг обнаружил проблему — статус должен измениться автоматически, без ожидания ручного подтверждения.
Обновление раз в час. Во время активного инцидента час — вечность. Пользователи думают, что вы забыли или не работаете над проблемой. 15-20 минут — максимальный интервал.
Технический жаргон. "OOM killed PID 4521 on worker-3b, restarting pod" — для вашего Slack-канала инцидентов, не для status page. Публичные updates — на языке пользователя.
Один общий статус вместо компонентов. "Service Disruption" — какой сервис? API? Dashboard? Payments? Пользователь хочет знать, затрагивает ли проблема его workflow.
Закрытие инцидента слишком рано. Фикс деплоили → инцидент закрыт → проблема вернулась через 10 минут → новый инцидент → закрыт → вернулась. Flapping status page хуже стабильно жёлтого статуса. Выдерживайте 15-30 минут мониторинга перед тем, как отмечать resolved.
FAQ
What is a status page?
A status page is a public-facing web page that shows the current operational state of your services. It lists individual components (API, Dashboard, Database), their status (operational, degraded, outage), active incidents with real-time updates, and a history of past incidents. It's the single source of truth for 'is the service working right now?'
Does every company need a status page?
If your product has users who depend on it being available — yes. You don't need a fancy one on day one. A simple page with 'operational' / 'investigating issue' / 'resolved' is infinitely better than nothing. The threshold is low: if you'd have to answer 'is it down?' more than once a month, you need a status page.
Should incidents be created automatically or manually?
Both. Automated creation from monitoring alerts catches outages instantly — no human delay. But the incident description and updates should be written by humans. A good workflow: monitoring auto-creates the incident with 'Investigating increased error rates', then an engineer posts human-written updates with context and timeline.
How transparent should I be about outages?
More transparent than you think. Users understand that systems fail. What they don't forgive is silence or dishonesty. Acknowledge the problem quickly, be honest about impact, update regularly, and publish a post-mortem after major incidents. Companies that do this consistently build stronger trust than those who pretend everything is always fine.
What's a good incident update cadence?
During active investigation: every 15-20 minutes. Once a fix is deployed and you're monitoring: every 30 minutes. If you have nothing new to say, say that: 'Still investigating, no new information. Next update in 15 minutes.' Silence is worse than a boring update.
Should I show uptime percentage on my status page?
For B2B SaaS with SLA commitments — yes, it demonstrates transparency and accountability. For consumer products — optional, since non-technical users may misinterpret 99.9% as unreliable. If you show it, use rolling 30 or 90 day windows so a single bad day doesn't dominate the metric for months.