When your service goes down, the first thing users do is check your status page. If you don't have one, they go to Twitter, write to support, or search "is [your service] down". Each of these paths is worse than a proper status page because you lose control of the narrative.
Below are 15 status pages from companies that do this well. Not just "pretty design," but concrete solutions: what to show, how to communicate, and what level of detail to provide.
Tier 1: Exemplary Status Pages
1. Stripe — status.stripe.com
Stripe processes billions of dollars. Their status page is a masterclass in clarity. Components are granular: API, Dashboard, Checkout, Connect, each payment method separate. If Klarna is down but cards work, you see it instantly.
Takeaway: granular component structure. Not just "API" as one block, but "Payments API," "Payouts API," "Reporting API." Users need to know what specifically broke, not just "something broke."
2. GitHub — githubstatus.com
GitHub shows not just current status but 90 days of uptime as a heat map — each day colored by incident count. This is a powerful transparency signal: "We don't hide our problems, we document them."
Takeaway: historical data. A status page without history is like a resume without experience. 90-day incident history shows the pattern: "One incident a month is normal. Ten incidents is a problem."
3. Cloudflare — cloudflarestatus.com
Cloudflare handles 20% of internet traffic. Their status page groups infrastructure by region and service type. Dashboard, API, CDN, DNS, SSL — all separate. Plus, subscribable incidents: get email notifications only for components you care about.
Takeaway: component subscriptions. A user who only uses DNS doesn't want alerts about Workers. Component filtering is respect for users' time.
Tier 2: Strong Communication
4. Slack — status.slack.com
Slack is the tool many use to receive monitoring alerts. When Slack itself goes down, it's meta-crisis: how do you notify people that the notification tool is broken? Their status page is clean, minimalist, focused on messaging, calls, files, and integrations as separate components.
Takeaway: minimalism. You don't need 50 components. Group by what users see: "Sending Messages," "Voice Calls," "File Uploads," "Search." This is clearer than "Message Server Cluster 3."
5. Datadog — status.datadoghq.com
Datadog is itself a monitoring service. Their status page must be perfect because it's literally their business. Components split into Core Platform and Individual Products, with separate rows for US1, EU1, US3, and other regions. Each incident includes detailed timeline with timestamps.
Takeaway: regional granularity. If you operate in multiple regions, show status of each. A problem in US-East doesn't affect EU — European users shouldn't panic.
6. Vercel — vercel-status.com
Vercel hosts millions of websites. Their status page is a model of conciseness: components (Deployments, Domains, Serverless Functions, Edge Network), 90-day uptime, and incident log with clear description of causes and timelines. Each incident links to a post-mortem.
Takeaway: link to post-mortem. After serious incidents, publish a root cause breakdown. This isn't weakness — it's strength. "Here's what broke, why it broke, and what we did to prevent it happening again."
7. Linear — linearstatus.com
Linear is project management for engineers. Their status page is a design benchmark: minimalism, clear typography, perfect hierarchy. Components grouped by user scenarios, not internal architecture. Subscriber notifications for email and webhook.
Takeaway: webhook subscriptions. For B2B customers integrating your status into their internal dashboards, a webhook with JSON payload is more valuable than an email notification.
Tier 3: Non-Obvious Solutions
8. Atlassian — status.atlassian.com
Atlassian combines dozens of products (Jira, Confluence, Bitbucket, Trello). Their status page solves a hard problem: showing status of each product and each region without information overload. The solution: two-level navigation: product → region → component.
9. AWS — health.aws.amazon.com
AWS Service Health Dashboard isn't the prettiest, but it's the most scalable status page in the world. Hundreds of services × dozens of regions = thousands of components. Filtering by region and service is necessary, not optional. Lesson: at scale, search and filters matter more than visual design.
10. Notion — status.notion.so
Notion attracts a non-technical audience. Their status page reflects this: minimal technical jargon, understandable descriptions ("Docs & wikis," "Search," "File uploads" instead of "Backend API v2"). Incident updates use plain language, not engineer-speak.
Takeaway: write for your audience. If your users aren't engineers, "Database connection pool exhausted" means nothing on a status page. "Document editing is slow — we're working on it" is clear.
11. Discord — discordstatus.com
Discord is community-first, and this shows in their status page. Components: Voice, API, Media Proxy, Push Notifications, Search — what users actually use. Incident updates are conversational, with honest acknowledgments: "this is taking longer than expected."
12. PagerDuty — status.pagerduty.com
Irony: PagerDuty is an alerting and incident service. When it goes down, teams lose their alerting pipeline. Their status page is a masterclass in detail: each component (Alerts, Events API, Scheduling, Mobile Push), uptime metrics, SMS subscription option (not just email).
Takeaway: SMS subscription. If your service is critical, an email notification about downtime might arrive late (or not at all if email depends on your own service). SMS is a more reliable channel for critical updates.
Tier 4: Niche but Instructive
13. Fly.io — status.fly.io
Fly.io targets developers. Their status page shows infrastructure by region (ams, cdg, fra, lhr, sin, syd...) — dozens of regions with individual status. For edge computing this is critical: a problem in one region doesn't affect others.
14. Resend — status.resend.com
Resend is an email API. Their status page is minimalist: API, Dashboard, Webhooks. For a single-product company, this is sufficient. Don't artificially inflate your status page with components — if you have one API and one frontend, two components is optimal.
15. Sentry — status.sentry.io
Sentry is error tracking. Their status page separates SDK ingestion (receiving events) from UI/Dashboard. This is smart: even if the dashboard is slow, events continue being captured. Users need to know: "Events are being recorded, just the dashboard is slow" — a totally different worry level than "Your errors are disappearing."
Common Patterns: What Great Status Pages Share
Components equal what users see. Not "Redis Cluster 3" or "Worker Node Pool B." But "Sending Messages," "File Uploads," "Search." Translate your internal architecture to user language.
Separate domain, separate infrastructure. status.yourcompany.com, hosted on different infrastructure than your main product. If your main infrastructure goes down, your status page should stay up.
Subscription to updates. Email, SMS, webhook, RSS — give users choice. Not everyone checks the status page manually; most want a notification.
Incident history. Minimum 90 days. Shows reliability pattern. One incident is coincidence, three is a trend.
Human language in updates. "We're investigating increased error rates in the EU region" is good. "P1 incident triggered, runbook 47b initiated" is bad for a public status page.
Building Your Own Status Page
Two approaches: build it yourself or use a hosted status page solution. Building yourself gives full control but requires maintaining separate infrastructure that must stay up when everything else is down. A hosted solution handles this for you.
AtomPing offers public status pages with a custom domain, automatic status updates based on monitoring, component structure, and incident history. Status pages run on dedicated edge infrastructure — they stay accessible even if your main service goes down.
Minimal setup: create monitors for each component → link them to your status page → configure incident rules → connect a custom domain. Result: a working status page in 15 minutes, updating automatically during incidents.
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.