Когда ваш сервис ложится, первое, что делают пользователи — проверяют status page. Если её нет, они идут в Twitter, пишут в поддержку, гуглят "is [your service] down". Каждый из этих путей — хуже, чем нормальная status page, потому что вы теряете контроль над нарративом.
Ниже — 15 status pages от компаний, которые делают это хорошо. Не просто "красивый дизайн", а конкретные решения: что показывать, как коммуницировать, какой уровень детализации давать.
Tier 1: Эталонные status pages
1. Stripe — status.stripe.com
Stripe обрабатывает миллиарды долларов. Их status page — эталон ясности. Компоненты разбиты гранулярно: API, Dashboard, Checkout, Connect, каждый payment method отдельно. Если Klarna не работает, а карты работают — вы видите это сразу.
Что взять: гранулярная компонентная структура. Не "API" одним блоком, а "Payments API", "Payouts API", "Reporting API". Пользователю важно знать, что именно сломалось, а не "что-то сломалось".
2. GitHub — githubstatus.com
GitHub показывает не только текущий статус, но и uptime за 90 дней в виде тепловой карты — каждый день раскрашен по количеству инцидентов. Это мощный transparency signal: "Мы не прячем наши проблемы, мы их документируем".
Что взять: исторические данные. Status page без истории — как резюме без опыта работы. 90-дневная история инцидентов показывает паттерн: "Один инцидент за месяц — нормально. Десять — повод беспокоиться".
3. Cloudflare — cloudflarestatus.com
Cloudflare обслуживает 20%+ интернет-трафика. Их status page группирует инфраструктуру по регионам и типам сервисов. Dashboard, API, CDN, DNS, SSL — всё отдельно. Плюс — subscribable incidents: получайте email-уведомления только по компонентам, которые вас интересуют.
Что взять: подписка на компоненты. Пользователь, который использует только DNS, не хочет получать алерты про Workers. Фильтрация по компонентам — это уважение к времени пользователя.
Tier 2: Сильная коммуникация
4. Slack — status.slack.com
Slack — инструмент, через который многие получают алерты от мониторинга. Когда Slack сам ложится, это мета-кризис: как уведомить людей, что инструмент уведомлений не работает? Их status page — чистая, минималистичная, с фокусом на messaging, calls, файлы и интеграции как отдельные компоненты.
Что взять: минимализм. Не нужно 50 компонентов. Группируйте по тому, что видит пользователь: "Отправка сообщений", "Звонки", "Загрузка файлов", "Поиск". Это понятнее, чем "Message Server Cluster 3".
5. Datadog — status.datadoghq.com
Datadog — сам мониторинговый сервис. Их status page должна быть идеальной, потому что это буквально их бизнес. Компоненты делятся на Core Platform и Individual Products, с отдельными строками для US1, EU1, US3 и других регионов. Для каждого инцидента — детальный timeline с timestamps.
Что взять: региональная детализация. Если вы работаете в нескольких регионах — показывайте статус каждого. Проблема в US-East не затрагивает EU — пользователи в Европе не должны паниковать.
6. Vercel — vercel-status.com
Vercel хостит миллионы сайтов. Их status page — образец лаконичности: компоненты (Deployments, Domains, Serverless Functions, Edge Network), uptime за 90 дней, и incident log с чётким описанием причин и таймлайнов. Каждый инцидент завершается post-mortem ссылкой.
Что взять: ссылка на post-mortem. После серьёзных инцидентов публикуйте разбор причин. Это не слабость — это сила. "Вот что сломалось, вот почему, вот что мы сделали, чтобы это не повторилось".
7. Linear — linearstatus.com
Linear — проект-менеджмент для инженеров. Их status page — дизайнерский эталон: минимализм, чёткая типографика, идеальная hierarchy. Компоненты группированы по пользовательским сценариям, а не по внутренней архитектуре. Subscriber notifications для email и webhook.
Что взять: webhook subscriptions. Для B2B клиентов, которые интегрируют ваш статус в свои внутренние дашборды — webhook с JSON payload ценнее email-уведомления.
Tier 3: Нетривиальные решения
8. Atlassian — status.atlassian.com
Atlassian объединяет десятки продуктов (Jira, Confluence, Bitbucket, Trello). Их status page решает сложную задачу: показать статус каждого продукта и каждого региона без информационного перегруза. Решение — двухуровневая навигация: продукт → регион → компонент.
9. AWS — health.aws.amazon.com
AWS Service Health Dashboard — не самая красивая, но самая масштабная status page в мире. Сотни сервисов x десятки регионов = тысячи компонентов. Фильтрация по регионам и сервисам — необходимость, не опция. Урок: при масштабе поиск и фильтры важнее визуализации.
10. Notion — status.notion.so
Notion привлекает нетехническую аудиторию. Их status page отражает это: минимум технического жаргона, понятные описания ("Docs & wikis", "Search", "File uploads" вместо "Backend API v2"). Incident updates написаны человеческим языком, а не инженерным.
Что взять: пишите для своей аудитории. Если ваши пользователи — не инженеры, "Database connection pool exhausted" на status page им ничего не скажет. "Document editing is slow — we're working on it" — понятнее.
11. Discord — discordstatus.com
Discord — community-first продукт, и это отражается в их status page. Компоненты: Voice, API, Media Proxy, Push Notifications, Search — то, что users реально используют. Incident updates — в разговорном тоне, с честными признаниями "this is taking longer than expected".
12. PagerDuty — status.pagerduty.com
Ирония: PagerDuty — сервис для алертов и инцидентов. Когда он ложится, команды теряют alerting pipeline. Их status page — образец детализации: каждый компонент (Alerts, Events API, Scheduling, Mobile Push), uptime метрики, subscriber option для SMS (не только email).
Что взять: SMS-подписка. Если ваш сервис критичен, email-уведомление о downtime может прийти с задержкой (или вовсе не прийти, если email зависит от вашего же сервиса). SMS — более надёжный канал для критических обновлений.
Tier 4: Нишевые, но поучительные
13. Fly.io — status.fly.io
Fly.io ориентирован на разработчиков. Их status page показывает инфраструктуру по регионам (ams, cdg, fra, lhr, sin, syd...) — десятки регионов с индивидуальным статусом. Для edge computing это критично: проблема в одном регионе не затрагивает остальные.
14. Resend — status.resend.com
Resend — email API. Их status page минималистична: API, Dashboard, Webhooks. Для single-product компании этого достаточно. Не раздувайте status page искусственными компонентами — если у вас один API и один фронтенд, два компонента — оптимально.
15. Sentry — status.sentry.io
Sentry — error tracking. Их status page разделяет SDK ingestion (приём событий) и UI/Dashboard. Это умно: даже если дашборд тормозит, данные продолжают собираться. Пользователям важно знать: "события записываются, просто дашборд медленный" — совсем другой уровень тревоги, чем "ваши ошибки пропадают".
Общие паттерны: что объединяет лучшие status pages
Компоненты = то, что видит пользователь. Не "Redis Cluster 3" и "Worker Node Pool B". А "Отправка сообщений", "Загрузка файлов", "Поиск". Переведите внутреннюю архитектуру на язык пользователя.
Отдельный домен, отдельная инфраструктура. status.yourcompany.com, размещённый на другом хостинге, чем ваш основной продукт. Если основная инфраструктура падает — status page должна остаться.
Подписка на обновления. Email, SMS, webhook, RSS — дайте пользователям выбор. Не все проверяют status page вручную; большинство хотят получить уведомление.
История инцидентов. Минимум 90 дней. Показывает паттерн reliability. Одинраз — случайность, три раза — проблема.
Человеческий язык в обновлениях. "We're investigating increased error rates in the EU region" — хорошо. "P1 incident triggered, runbook 47b initiated" — плохо для публичной status page.
Как построить свою status page
Два подхода: строить самостоятельно или использовать hosted status page. Самостоятельная разработка даёт полный контроль, но требует поддержки отдельной инфраструктуры, которая должна быть доступна когда всё остальное лежит. Hosted решение берёт это на себя.
AtomPing предлагает публичные status pages с кастомным доменом, автоматическим обновлением статуса на основе мониторинга, компонентной структурой и историей инцидентов. Status page работает на отдельной edge-инфраструктуре — она останется доступной, даже если ваш основной сервис упадёт.
Минимальная конфигурация: создайте мониторы для каждого компонента → привяжите их к status page → настройте правила инцидентов → подключите кастомный домен. На выходе — рабочая status page за 15 минут, которая обновляется автоматически при инцидентах.
FAQ
What should a status page include?
At minimum: current status of each service (operational, degraded, outage), active incidents with updates, and a timeline of recent incidents. Good status pages also show uptime metrics (30/90 day), response time graphs, and planned maintenance schedules. The best ones include component-level granularity so users can see exactly which part of the system is affected.
Should my status page be on a separate domain?
Yes, ideally. If your main infrastructure goes down, your status page should still be accessible. Host it on a separate domain (status.yourcompany.com) with different infrastructure. AtomPing status pages run on dedicated edge infrastructure specifically for this reason — they stay up even if your main site is down.
How often should I update the status page during an incident?
Every 15-30 minutes during an active incident, even if the update is 'still investigating.' Users are far more frustrated by silence than by slow progress. The worst thing you can do is mark an incident as 'investigating' and not update for 2 hours. Set a timer — if you haven't posted an update in 20 minutes, post one.
Should I show uptime percentage on my status page?
It depends on your audience. B2B SaaS with SLA commitments — yes, show 30/90 day uptime. It builds trust and demonstrates transparency. Consumer-facing products often skip this because 99.9% sounds like 'sometimes broken' to non-technical users. If you show it, make sure you can actually maintain it.
Do status pages actually reduce support tickets?
Significantly. Companies report 30-50% fewer support tickets during outages when they have a well-maintained status page. Users check the status page first, see that the team is aware, and wait instead of filing tickets. The ROI of a status page is primarily in reduced support load during incidents.
What's the difference between a public and internal status page?
A public status page is visible to everyone — customers, prospects, the internet. An internal status page shows more technical detail and is accessible only to your team: database latency, queue depth, individual microservice health. Many companies run both — public for customers, internal for engineering.