В январе 2023 года Slack лежал 4 часа. Пользователи узнали об этом не с status page, а из Twitter — потому что status.slack.com показывал "All Systems Operational" первые 40 минут после начала outage. В марте 2024 года, когда у Cloudflare случился инцидент с потерей логов, их status page обновлялся каждые 12 минут с конкретикой: какие сервисы затронуты, какой процент трафика потерян, какой fix деплоится.
Разница между этими двумя подходами — не технология. Это разница в отношении к status page: декорация vs. инструмент коммуникации.
Status page — один из немногих каналов, где ваша компания говорит с пользователями в самый уязвимый момент: когда что-то сломалось. То, как вы это делаете, определяет, останутся ли пользователи после инцидента.
Зачем нужна status page
Status page решает три проблемы, которые не решает ни один другой канал коммуникации.
Проблема 1: "Это у меня или у вас?"
Когда пользователь видит ошибку, его первая мысль: "Это моё подключение, мой браузер, или сервис лежит?" Без status page он идёт в Google: "is [your service] down". Попадает на DownDetector, Reddit, Twitter. Вы теряете контроль над нарративом — кто-то пишет "лежит уже час", хотя инцидент начался 5 минут назад.
Status page перехватывает этот запрос. Пользователь видит: "API — Degraded Performance. Investigating increased error rates for EU region. 14:32 UTC." Он понимает: команда в курсе, починка идёт. Не нужно писать в поддержку, не нужно гуглить.
Проблема 2: поддержка тонет в одинаковых тикетах
Во время outage каждый пользователь, столкнувшийся с ошибкой, пишет в support. Десять пользователей — десять тикетов с одинаковым содержанием: "Не работает". Поддержка тратит время на одинаковые ответы вместо того, чтобы эскалировать проблему инженерам.
Компании с работающей status page фиксируют на 30-50% меньше тикетов во время инцидентов. Пользователь проверяет status page, видит, что проблема известна, и ждёт — вместо того, чтобы писать в поддержку.
Проблема 3: внутренняя координация
Status page — не только для внешних пользователей. Когда инцидент открыт, CEO, VP Sales, Support Lead и инженеры хотят знать одно и то же: что сломалось, кого затронуло, когда починят. Без единого источника правды каждый спрашивает у инженеров, которые в этот момент должны чинить, а не отвечать на вопросы.
Status page становится этим единым источником. Инженер пишет update — все видят. Менеджер аккаунтов отправляет ссылку клиенту. VP Sales видит timeline и понимает масштаб. Никто не дёргает инженеров в Slack с вопросом "ну что там?".
Анатомия status page: из чего она состоит
Рабочая status page состоит из пяти блоков. Каждый решает конкретную задачу.
1. Общий статус (Overall Status)
Первое, что видит пользователь при загрузке страницы. Крупный индикатор: "All Systems Operational" (зелёный), "Some Systems Experiencing Issues" (жёлтый), "Major Service Disruption" (красный). Задача — дать ответ за 1 секунду: "Всё нормально" или "Что-то не так, читай дальше".
Важный нюанс: общий статус должен агрегироваться автоматически из статусов компонентов. Если хотя бы один компонент в Partial Outage — общий статус не может быть "All Operational". Лучшие status pages используют "worst-of" логику: общий статус = наихудший статус среди компонентов.
2. Список компонентов
Компоненты — это сервисы или функции, которые вы мониторите и показываете пользователям. Ключевой принцип: компоненты = пользовательские сценарии, а не внутренняя архитектура. Пользователь не знает, что такое "Worker Pool B" или "Redis Cluster EU-3". Он знает, что не может загрузить файл или отправить сообщение.
Правильная группировка:
SaaS: Dashboard, API, Authentication, File Storage, Search, Notifications, Billing
E-commerce: Website, Product Catalog, Cart & Checkout, Payments, Order Tracking, Support
Infrastructure: API, Dashboard, Webhooks, EU Region, US Region, APAC Region
Communication: Messaging, Voice, Video, File Sharing, Integrations
Неправильная группировка:
"PostgreSQL Primary", "Redis Sentinel", "Celery Workers", "Kubernetes Pods" — пользователь не знает, что это, и не может определить, затрагивает ли его это.
Оптимальное количество: 5-15. Меньше — слишком грубо. Больше — перегруз. Для каждого компонента — один из четырёх статусов:
Operational — работает в штатном режиме.
Degraded Performance — работает, но медленнее или с ограничениями.
Partial Outage — часть функциональности или пользователей затронута.
Major Outage — недоступен для большинства пользователей.
Не смешивайте статусы компонентов и стадии инцидента. "Investigating" и "Monitoring" — это стадии инцидента, а не статусы компонента. Компонент либо работает, либо деградирован, либо упал.
3. Активные инциденты
Когда что-то сломалось — инцидент выходит на первый план. Каждый инцидент содержит:
Заголовок: краткое описание проблемы ("Increased API Error Rates in EU Region")
Затронутые компоненты: какие сервисы задеты
Текущая стадия: Investigating → Identified → Monitoring → Resolved
Timeline обновлений: хронологическая лента с timestamps
Обновления в инциденте — самый важный элемент. Именно их читают пользователи. Подробнее о том, как писать обновления — в отдельной статье. Здесь — ключевые принципы.
4. История инцидентов
90-дневная лента прошлых инцидентов. Две задачи: (1) пользователь может проверить, были ли проблемы вчера, когда он заметил странное поведение, и (2) потенциальный клиент может оценить надёжность сервиса перед покупкой.
GitHub делает это особенно хорошо: тепловая карта за 90 дней, где каждый день раскрашен по количеству инцидентов. Пустые дни — зелёные. Один инцидент — жёлтый. Несколько — красный. За 2 секунды видна вся картина.
5. Метрики и uptime
Продвинутые status pages показывают количественные данные: uptime percentage за 30/90 дней, response time графики. Это сильный transparency signal. Одно дело — сказать "у нас высокая надёжность". Другое — показать 99.95% uptime с публичным графиком, где виден каждый инцидент.
Для B2B SaaS c SLA-обязательствами это практически обязательно. Для consumer-продуктов — опционально, поскольку нетехнические пользователи могут неверно интерпретировать 99.9% как "иногда ломается".
Типы status pages
Не все status pages одинаковы. В зависимости от аудитории и целей, выделяются три основных типа.
Public status page
Открыта для всех — клиентов, потенциальных пользователей, прессы. Это витрина вашей операционной зрелости. Показывает компоненты, инциденты, uptime. Доступна по адресу вроде status.yourcompany.com или yourcompany.com/status.
Кому нужна: любой SaaS, API-сервис, платформа. Фактически — любой бизнес, где пользователи зависят от доступности продукта.
Internal status page
Доступна только внутри организации. Показывает больше технических деталей: latency по эндпоинтам, глубина очереди, состояние отдельных микросервисов, health checks баз данных. Это dashboard для инженеров и SRE.
Разница с Grafana: status page фиксирует состояния и инциденты. Grafana показывает метрики. Инженеру нужно и то, и другое: status page говорит "что сломалось и когда", Grafana — "почему и насколько".
Audience-specific status page
Ограниченная status page для конкретной группы: VIP-клиенты, партнёры, определённая команда. Показывает только те компоненты, которые релевантны этой аудитории. Крупные платформы (AWS, Datadog) предоставляют такие: enterprise-клиент видит только свой регион и свои сервисы.
Создание status page для каждого типа аудитории требует разной глубины: клиентская — лаконичная, инженерная — детальная, VIP — персонализированная.
Как писать обновления во время инцидентов
Компонентная структура — скелет status page. Обновления инцидентов — её сердце. Это то, что пользователи читают, когда что-то сломалось. И то, по чему они судят о вашей компании.
Формула обновления: Что + Кого + Что делаем
Каждое обновление отвечает на три вопроса:
Что происходит: конкретная проблема, не общие слова
Кого затрагивает: какие пользователи, регионы, функции
Что мы делаем: текущее действие и следующий шаг
Плохой пример:
"We're experiencing some issues. Our team is looking into it."
Хороший пример:
"API requests to /v2/payments are returning 503 errors for approximately 15% of requests in the EU region. We've identified an issue with connection pooling in our payment processing service and are deploying a fix. ETA: 20 minutes."
Разница: конкретный эндпоинт, конкретный процент, конкретный регион, конкретная причина, конкретный ETA. Пользователь получает достаточно информации, чтобы решить: ждать, переключиться на fallback или позвонить своим клиентам.
Стадии инцидента
Стандартная модель — четыре стадии. Каждая сигнализирует пользователю разное:
Investigating — проблема обнаружена, команда разбирается. Пользователь знает: "Они в курсе".
Identified — причина найдена, fix в разработке. Пользователь знает: "Они понимают, что случилось".
Monitoring — fix задеплоен, наблюдаем за стабильностью. Пользователь знает: "Скоро нормализуется".
Resolved — проблема решена, сервис восстановлен. Пользователь знает: "Можно работать дальше".
Cadence: как часто обновлять
Правило: каждые 15-20 минут во время активного расследования. Если нечего нового сказать — скажите это: "Продолжаем расследование, новой информации пока нет. Следующее обновление через 15 минут." Тишина хуже скучного обновления. Тишина заставляет пользователя думать, что о проблеме забыли.
После деплоя fix'а: обновляйте каждые 30 минут, пока не убедитесь в стабильности. Закройте инцидент через 1-2 часа стабильной работы с итоговым summary.
Тон коммуникации
Factual, спокойный, конкретный. Не извиняйтесь в каждом обновлении — одно искреннее извинение в конце инцидента ценнее десяти "We apologize for the inconvenience". Не используйте уклончивый язык: "some users may experience" → "15% of EU API requests are failing". Чем конкретнее — тем больше доверия.
Отдельный антипаттерн — blame shifting. "Our cloud provider is experiencing issues" — даже если это правда, пользователю всё равно. Его SLA — с вами, не с AWS. Лучше: "A third-party infrastructure issue is causing API latency. We've engaged their support team and are evaluating failover to our backup region."
Интеграция с мониторингом
Status page без мониторинга — ручной процесс. Кто-то должен заметить проблему, открыть status page, создать инцидент, написать обновление. Это минуты задержки, которые складываются в десятки минут — а стоимость даунтайма считается не в минутах, а в долларах.
Автоматическое создание инцидентов
Правильная цепочка: мониторинг обнаруживает проблему → система автоматически создаёт инцидент на status page → уведомление уходит команде → инженер добавляет human-readable обновление.
Автоматизировать можно и нужно: обнаружение проблемы, создание инцидента, первичное обновление ("Investigating elevated error rates on API"), изменение статуса компонента. Не автоматизируйте содержание обновлений — "Alert fired: HTTP check returned 503" не помогает пользователю. Пусть автоматика откроет инцидент за 10 секунд, а инженер через 3 минуты добавит нормальное объяснение.
Какие проверки привязывать к компонентам
Каждый компонент на status page должен быть привязан к конкретным мониторинг-проверкам:
API: HTTP-проверка ключевых эндпоинтов + response time мониторинг
Authentication: HTTP-проверка login endpoint + keyword check на наличие token в ответе
Website: HTTP + keyword ("Sign In" присутствует на странице) + PageSpeed
Database: TCP-проверка порта + health check endpoint
Email: DNS-проверка MX-записей + SSL-мониторинг
Background Jobs: Heartbeat-мониторинг cron jobs
Правило: если компонент на status page не привязан ни к одной проверке — его статус обновляется вручную, а значит — с задержкой. Synthetic monitoring позволяет проверять каждый сценарий автоматически, без зависимости от того, кто из инженеров сейчас онлайн.
Multi-region мониторинг и false positives
Одна неудачная проверка из одного региона — не повод менять статус компонента на status page. Сеть между мониторинг-агентом и вашим сервером могла кратковременно сбоить. Именно поэтому мониторинг должен быть мультирегиональным с подтверждением: инцидент создаётся только когда несколько агентов из разных точек подтверждают проблему.
Подробнее про устранение ложных срабатываний — в отдельном гайде. Здесь важен принцип: status page должна отражать реальное состояние сервиса, а не шум от нестабильной сети мониторинга.
Инфраструктура status page
Ирония status page: она нужна именно тогда, когда всё ломается. Если status page лежит вместе с основным сервисом — она бесполезна. Инфраструктура status page должна быть независимой от основной.
Отдельная инфраструктура
Минимальный набор: другой хостинг-провайдер, другой DNS, другой CDN. Если ваш основной сервис на AWS — status page не должна быть на AWS. Не обязательно строить свою: managed-решения (AtomPing, Statuspage, Instatus) уже работают на выделенной инфраструктуре.
Отдельный домен: status.yourcompany.com — стандарт отрасли. Некоторые компании используют yourcompanystatus.com (GitHub — githubstatus.com), чтобы даже DNS-зона была изолирована. AtomPing позволяет подключить custom domain для status page с автоматическим SSL.
Performance и доступность
Status page должна загружаться мгновенно. Когда пользователь проверяет "it's down?" — он нетерпелив. Каждая секунда загрузки снижает доверие. Оптимально: статическая страница (HTML + CSS), раздаваемая через CDN, с динамическим обновлением статусов через lightweight API или SSE (Server-Sent Events).
Тяжёлые SPA-приложения (React/Vue бандл в 500KB) для status page — антипаттерн. Пользователь ждёт, пока загрузится JavaScript, инициализируется приложение, сделается API-запрос — на плохом мобильном интернете это 5+ секунд. Лучший подход: server-rendered HTML с инкрементальными обновлениями.
Подписки и уведомления
Активная status page не ждёт, пока пользователь зайдёт и проверит. Она уведомляет подписчиков:
Email: самый универсальный канал. Пользователь подписывается, получает уведомления при создании/обновлении/закрытии инцидентов.
Webhook: для автоматизации. Ваш клиент может интегрировать вашу status page в свой внутренний мониторинг или Slack.
RSS/Atom: классический формат для тех, кто агрегирует статусы нескольких сервисов.
Компонентные подписки: пользователь подписывается только на те компоненты, которые его касаются. Cloudflare делает это хорошо — можно подписаться только на DNS или только на Workers.
Дизайн и UX: как сделать status page удобной
Discoverability: как пользователи находят status page
Самая красивая status page бесполезна, если пользователи не знают о ней. Точки входа:
Footer сайта и приложения: ссылка "System Status" в каждом footer. Стандарт индустрии.
Страница ошибки: на 500/503 странице — "Проверьте текущий статус сервиса: status.yourcompany.com".
Страница логина: если пользователь не может залогиниться, ссылка на status page — первое, что он должен увидеть.
Документация: раздел "Service Status" в docs с прямой ссылкой.
Баннер в приложении: при активном инциденте — неинтрузивный баннер в UI: "We're aware of issues with [component]. Details: status page link".
Брендинг
Status page — часть вашего бренда. Она должна выглядеть как ваш продукт: ваш логотип, ваши цвета, ваш шрифт. Чужеродная status page (generic шаблон с другими цветами) подрывает доверие: "Это точно их страница, или фишинг?"
Кастомный домен усиливает брендинг. status.yourcompany.com > yourcompany.statuspage.io. Показывайте пользователю вашу идентичность даже в момент кризиса.
Мобильный опыт
Большинство проверок "is it down?" происходит с телефона. Инженер в нерабочее время получает алерт и открывает status page на телефоне. Клиент замечает проблему в мобильном приложении и тут же гуглит статус. Status page должна быть responsive, быстро загружаться на 3G, и не требовать горизонтального скролла.
Post-mortem: что делать после инцидента
Закрыть инцидент на status page — не конец. Для серьёзных инцидентов (Major Outage, длительный Partial Outage, data loss) нужен post-mortem — публичный или внутренний.
Публичный post-mortem
Структура, которая работает:
Summary: что случилось, как долго, кого затронуло
Timeline: хронология событий с timestamps (обнаружение → диагностика → fix → recovery)
Root Cause: техническая причина без blame. "Database connection pool exhausted due to a connection leak introduced in release 3.4.1" — не "Dave deployed bad code"
Impact: конкретные цифры. "12% of API requests failed over 47 minutes. Approximately 2,300 users affected."
Action Items: что сделаете, чтобы это не повторилось. Конкретные задачи с ответственными и сроками, не абстрактные "improve monitoring".
Публикация post-mortem — акт доверия. Cloudflare, GitHub, Stripe публикуют детальные post-mortem после каждого серьёзного инцидента. Это не слабость — это показатель зрелой инженерной культуры.
Внутренний post-mortem
Для инцидентов, которые не заслуживают публичного post-mortem (внутренняя деградация, пойманная до влияния на пользователей), проводите внутреннюю ретроспективу. Та же структура, но с большей технической глубиной: метрики, графики, code diffs. И главное — blameless: фокус на системных причинах, а не на том, кто ошибся.
Чему можно научиться у лучших
Анализ 15 лучших status pages выявляет общие паттерны, которые стоит перенять:
Stripe: гранулярная компонентная структура. Не "API", а "Payments API", "Payouts API", "Reporting API". Пользователь видит, что именно работает, а что нет.
GitHub: 90-дневная тепловая карта инцидентов. Прозрачность через исторические данные: "Мы не прячем проблемы".
Cloudflare: подписки на отдельные компоненты. Пользователь DNS не получает алерты про Workers.
Datadog: региональная группировка. Компоненты разбиты по US, EU, AP — пользователь смотрит только свой регион.
Linear: минимализм. Никакого визуального шума, только статусы и обновления. Информационная плотность высокая, cognitive load низкий.
Как запустить status page: пошаговый план
Шаг 1: определите компоненты
Начните с вопроса: "Какие действия выполняют наши пользователи?" Каждое действие — потенциальный компонент. Логин, работа с API, загрузка файлов, оплата, просмотр отчётов. Сгруппируйте по функциональности, оставьте 5-15.
Шаг 2: настройте мониторинг для каждого компонента
Каждый компонент должен быть привязан к хотя бы одной synthetic проверке. Используйте мультирегиональный мониторинг, чтобы отличить реальную проблему от сетевого шума. Настройте пороги: response time > 2s = degraded, 503 от 3+ регионов = outage.
Шаг 3: подключите автоматическое создание инцидентов
Свяжите мониторинг со status page. Когда срабатывает incident detection — инцидент создаётся автоматически: название, затронутые компоненты, начальное обновление. Инженеру остаётся только дописать человеческое объяснение.
Шаг 4: определите процесс обновления
Кто пишет обновления? Когда? Какой уровень детализации? Определите это до первого инцидента. В идеале — шаблон: "Investigating: [что случилось] affecting [кого]. We're looking into [что делаем]. Next update in [N] minutes." Практика incident communication должна быть задокументирована в runbook.
Шаг 5: сделайте status page находимой
Добавьте ссылку в footer, на страницу ошибки, в документацию, на страницу логина. Включите подписки по email и webhook. Протестируйте: попросите коллегу найти status page за 10 секунд. Если не получается — точки входа недостаточно заметны.
Шаг 6: обкатайте на учебном инциденте
Не ждите реального outage, чтобы проверить процесс. Проведите fire drill: создайте тестовый инцидент, напишите обновления, пройдите весь lifecycle от Investigating до Resolved. Убедитесь, что уведомления уходят, status page обновляется, и команда знает порядок действий.
Распространённые ошибки
"All Systems Operational" во время видимого инцидента
Главная причина потери доверия к status page. Если пользователи видят ошибки, а status page зелёная — они больше не будут её проверять. Решение: автоматическое создание инцидентов от мониторинга. Человек может не заметить проблему, автоматика — заметит.
Слишком мало обновлений
Инцидент открыт 2 часа, единственное обновление — "Investigating". Пользователь не знает: работает ли кто-то над проблемой? Есть ли прогресс? Когда ждать fix? Даже "No new information, continuing investigation" лучше тишины.
Слишком много компонентов
40 компонентов, из которых пользователь узнаёт 3. Остальные — внутренние сервисы с техническими названиями. Status page становится dashboard инженера, а не инструментом для пользователя. Если компонент нужен только вашей команде — вынесите его на internal status page.
Отсутствие post-mortem
Серьёзный инцидент закрыт, пользователи спрашивают "что случилось?" — а в ответ тишина. Post-mortem показывает, что вы разобрались в причинах и приняли меры. Без него пользователь полагает, что проблема повторится.
Status page на той же инфраструктуре
Основной сервис на AWS, status page — тоже на AWS, в том же регионе. AWS US-East-1 падает — и сервис, и status page лежат одновременно. Пользователь не может ни воспользоваться сервисом, ни узнать, что происходит. Отдельная инфраструктура — не рекомендация, а требование.
Status page как конкурентное преимущество
В 2026 году status page — не дифференциатор, а гигиенический фактор. Её отсутствие — красный флаг. Enterprise-клиенты спрашивают "где ваша status page?" на этапе evaluation. Если ответа нет — доверие падает ещё до начала пилота.
Но качество status page по-прежнему отличает зрелые команды от остальных. Быстрые обновления, конкретика вместо общих фраз, публичные post-mortem, подписки по компонентам, исторические данные — всё это формирует восприятие: "Эта команда знает, что делает. Они прозрачны. Им можно доверять."
Инвестиция в status page — это инвестиция в устойчивость к даунтаймам. Не техническая устойчивость (это задача инфраструктуры), а коммуникационная: способность сохранять доверие пользователей даже тогда, когда технология подводит.
Чеклист: готова ли ваша status page
Компоненты: 5-15 штук, названы по пользовательским сценариям, не по внутренней архитектуре
Мониторинг: каждый компонент привязан к проверкам из нескольких регионов
Автоматизация: инциденты создаются автоматически при срабатывании мониторинга
Процесс: задокументирован runbook — кто пишет обновления, с какой периодичностью
Инфраструктура: status page на отдельной инфраструктуре от основного сервиса
Находимость: ссылка в footer, на странице ошибки, в документации, на странице логина
Подписки: email и webhook уведомления для подписчиков
Брендинг: custom domain, логотип, цвета вашего бренда
Post-mortem: процесс публикации post-mortem после серьёзных инцидентов
Fire drill: проведён тестовый инцидент, команда знает процесс
Связанные материалы
Status Page Best Practices — детальный гайд по компонентной структуре и incident communication
15 Best Status Page Examples — разбор status pages от Stripe, GitHub, Cloudflare и других
How to Create a Status Page — пошаговое руководство по созданию
Complete Guide to Uptime Monitoring — всё о мониторинге, который питает status page
How to Reduce False Alarms — чтобы status page не мигала от ложных срабатываний
SLA vs SLO vs SLI — метрики надёжности, которые показывают на status page
Cost of Downtime — зачем всё это: цена каждой минуты без status page
FAQ
What is a status page?
A status page is a dedicated web page that shows the real-time operational state of your services. It lists components (API, Dashboard, Payments), their current status (operational, degraded, outage), active incidents with timestamped updates, and incident history. It's the canonical source for 'is the service working right now?' — both for your customers and your internal team.
Do I need a status page if I have few users?
If your product has paying users or business-critical integrations — yes. Even 10 enterprise customers will ask 'is it down?' during an outage. A status page replaces manual Slack messages and email threads with a single, always-current source. The threshold is low: if you've ever had to answer 'is the service down?' twice in one week, a status page will save time.
Should my status page be hosted separately from my main app?
Yes. If your primary infrastructure fails, your status page should remain accessible. Best practice: host status pages on separate infrastructure, ideally a different provider and domain. AtomPing status pages run on dedicated edge servers independent of your application — so they stay up when your app goes down.
How many components should a status page have?
Between 5 and 15. Fewer than 5 is too coarse — users can't tell what's broken. More than 15 creates noise — users won't scan a long list to find their component. Group by user-facing functionality (Authentication, API, File Upload), not internal architecture (Redis Cluster 3, Worker Pool B).
Should incidents be created automatically?
Detection should be automatic, but communication should be human-reviewed. Monitoring systems auto-detect and auto-create incidents instantly. Then an engineer writes the actual update: what's happening, who's affected, what you're doing about it. Fully automated messages ('Alert: HTTP check failed') read as robotic and erode trust.
What's the ROI of a status page?
Companies report 30-50% fewer support tickets during outages when they maintain an active status page. Beyond support deflection: faster internal response (everyone sees the same incident timeline), improved customer trust (transparency builds loyalty), and reduced churn after incidents (customers stay when they feel informed).
Can I use a status page for planned maintenance?
Yes, and you should. Schedule maintenance windows in advance so subscribers get notified before the downtime. During maintenance, the status page shows which components are affected and estimated completion time. This prevents users from filing 'is it down?' tickets during planned work.
How do I get people to actually check the status page?
Three things: make it discoverable (link from your app's footer, error pages, login screen, and docs), make it subscribable (email and webhook notifications so people don't have to check manually), and make it trustworthy (update it consistently during every incident — if it's stale once, people stop checking).