We analyzed status pages from companies of all sizes — from tech giants like GitHub and Stripe to smaller SaaS products — to identify what works, what doesn't, and what you can steal for your own.
This isn't a theoretical guide. Every example is a real, live status page you can visit right now. We'll break down what each does well and where they fall short.
What Makes a Great Status Page
The Checklist Before We Dive In
Before looking at examples, here's what separates good status pages from bad ones:
Let's see how real companies handle these.
Enterprise Examples
Example 1: GitHub
githubstatus.comWhat they do well:
- Component breakdown is excellent: Git Operations, API Requests, Actions, Packages, Pages, Codespaces, Copilot — each with independent status
- Clear three-state system: Operational, Degraded Performance, Major Outage
- Incident history with detailed timelines showing every update
- 90-day uptime graph per component gives historical context
- Subscriber notifications via email, SMS, webhook, Atom/RSS
What they could improve:
- During major incidents, updates sometimes lag behind their Twitter/X communications
- The page design is functional but plain
Why it works:
GitHub's user base is technical and expects detailed component-level information. Their status page delivers exactly that.
Example 2: Stripe
status.stripe.comWhat they do well:
- Clean, minimal design that communicates urgency without panic
- Separates API, Dashboard, and individual Stripe products (Connect, Billing, Terminal, etc.)
- Response time graph shows real-time API performance
- Extremely detailed incident reports with root cause analysis posted afterward
- Scheduled maintenance announcements with clear time windows
What they could improve:
- Could show regional breakdowns (US vs EU API performance)
Why it works:
For a payment processor, trust is everything. Stripe's status page reinforces trust through transparency and detail.
Example 3: Cloudflare
cloudflarestatus.comWhat they do well:
- Geographic breakdown — shows status per data center region, critical for a CDN
- Clear separation between Cloudflare Dashboard, API, and edge network
- Very frequent updates during incidents (sometimes every 5 minutes)
- Detailed post-incident reports published afterward
- Third-party hosting (not on Cloudflare itself) so it stays up during Cloudflare outages
What they could improve:
- The page can feel overwhelming with hundreds of components listed
Why it works:
Cloudflare serves millions of sites. Regional granularity matters because a problem in Tokyo doesn't affect London users.
Example 4: AWS
health.aws.amazon.comWhat they do well:
- Per-service, per-region status — extremely granular
- Historical timeline of events
- Service health dashboard is a canonical reference for cloud status
What they could improve:
- Notoriously slow to update during actual incidents — Twitter/X often has information faster
- The interface is complex and not user-friendly
- Some incidents are reported as "elevated error rates" when services are effectively down
Why it works (and doesn't):
AWS provides the data, but their communication speed during incidents has been widely criticized. Granularity without timeliness defeats the purpose.
SaaS Examples
Example 5: Linear
linearstatus.comWhat they do well:
- Beautiful, clean design that matches their brand aesthetic
- Simple component list: App, API, Git Integration, Webhooks
- 90-day uptime percentage prominently displayed — shows confidence
- Incident history is transparent and well-written with human language
What they could improve:
- Could add response time graphs
Why it works:
Linear's audience (dev teams) values both quality and transparency. Their status page reflects the same design philosophy as their product.
Example 6: Vercel
vercel-status.comWhat they do well:
- Component status for Deployments, Serverless Functions, Edge Network, etc.
- Clear incident timeline with technical detail
- Subscriber notifications via multiple channels
- 90-day component-level uptime history
What they could improve:
- Regional breakdown would help since they're a global edge platform
Why it works:
Developers deploying on Vercel need to know exactly which part of the deployment pipeline is affected.
Example 7: Notion
status.notion.soWhat they do well:
- Very clean, user-friendly design
- Simple categories: Notion App, API, Website
- Clear incident communication with regular updates
- Historical uptime displayed prominently
What they could improve:
- Could be more granular (separate mobile app, desktop app, specific features)
Why it works:
Notion serves both technical and non-technical users. The simplicity makes it accessible to everyone.
Example 8: Datadog
status.datadoghq.comWhat they do well:
- Granular per-product status (Metrics, APM, Logs, Synthetics, etc.)
- Per-region status (US1, US3, US5, EU1, AP1, etc.)
- Detailed incident timelines
What they could improve:
- The design is utilitarian — fits a monitoring company but could be cleaner
Why it works:
Datadog is a monitoring platform. If their status page wasn't excellent, it would undermine their entire value proposition.
Indie/Small Team Examples
Example 9: Plausible Analytics
What they do well:
- Simple, clean status page matching their brand (privacy-focused, minimal)
- Honest communication during incidents
- The simplicity matches their product philosophy
Takeaway for indie makers:
You don't need 50 components. If you have a simple product, a simple status page is perfect.
Example 10: Cal.com
What they do well:
- Open-source product, open status page — consistent values
- Component separation for API, Dashboard, Booking
- Community-oriented update language
Takeaway for indie makers:
Your status page communication should match your brand voice.
Example 11: Buttondown
What they do well:
- Honest, human tone in incident updates
- Simple component list matching their simple product
- No over-engineering
Takeaway for indie makers:
Status pages don't need to be complex. List your 3-5 core components and communicate honestly.
Example 12: The ideal indie maker setup
Here's what a great indie maker status page looks like:
- Website / App
- API
- Payments / Billing
- Email Notifications
That's it. Four components. Update them honestly during incidents. Display 90-day history. Allow email subscriptions.
You can set this up in 60 seconds with an emergency status page tool and formalize it later with a proper monitoring setup.
Common Patterns Worth Copying
After analyzing dozens of status pages, here are the patterns that work:
1. Three-state minimum
Operational → Degraded → Major Outage. Some add "Partial Outage" and "Under Maintenance" for more nuance.
2. Component grouping
Group related items. "Infrastructure" (API, CDN, DNS) vs "Products" (Dashboard, Mobile App, Integrations).
3. Uptime history visualization
A 90-day bar chart where each day is green/yellow/red is universally understood. Users don't need to read numbers — the visual tells the story.
4. Incident timeline format
Identified → Investigating → Monitoring → Resolved. This four-stage pattern (from Atlassian Statuspage) has become a de facto standard.
5. Subscriber options
Email at minimum. Webhook for technical users. SMS for critical services. RSS for monitoring tools.
6. Separate hosting
Your status page MUST be on different infrastructure than your app. If they share hosting, both go down together.
Related: Downtime vs degraded performance — understanding the states your status page should communicate.
Common Mistakes to Avoid
The "always green" status page
If your status page never shows incidents, users stop trusting it. Transparency builds trust; false perfection destroys it.
Slow updates during incidents
Silence is worse than bad news. Update every 15-30 minutes even if the update is "still working on it."
Corporate jargon
"We are currently experiencing intermittent service degradation across a subset of our infrastructure" means nothing to users. Say "Some users can't log in. We're fixing it. ETA: 30 minutes."
No incident history
A status page without history is a marketing page, not a trust tool.
Same hosting as the main app
The one time you need your status page is the one time your hosting is down.
Too many components
Listing 50 microservices confuses users. Group them into user-facing categories.
No subscription option
Forcing users to manually check the page is a bad experience. Let them subscribe.
How to Build Your Own
You have three options:
Option 1: Emergency status page (free, instant)
When something breaks RIGHT NOW and you need to communicate. No signup, live in 60 seconds.
Best for: Immediate crisis communication.
Option 2: Monitoring tool with built-in status pages
Set up monitoring that automatically updates your status page based on real check results. Components reflect actual system health.
Best for: Ongoing, automated status communication.
Option 3: Standalone status page platforms
Dedicated status page tools like Atlassian Statuspage ($29+/mo). More customization, but another tool to manage and pay for.
Best for: Enterprise teams with complex requirements.
For most indie makers and small SaaS teams, Option 2 makes the most sense. You get monitoring AND status pages in one tool, and the status page stays accurate automatically because it's connected to real monitoring data.
PerkyDash combines uptime monitoring with full-featured status pages. Your status page updates automatically based on real monitoring results.
Start free — monitoring + status pages includedConclusion
The best status pages share three qualities: they're honest, they're timely, and they're simple.
You don't need Cloudflare's geographic granularity or AWS's per-service breakdown. You need a page that tells users what's working, what's not, and when it'll be fixed.
Start simple. List your core components. Update them honestly during incidents. Display your history. Let people subscribe. That's it. That's a status page that builds trust.
Related reading: Status page best practices • Incident communication • SLA uptime explained • Post-mortem template
Ready to Build Your Status Page?
Whether you need an emergency page right now or a permanent monitoring + status page setup, we've got you covered.
Frequently Asked Questions
What should a status page include?
A good status page includes component-level system status, current incident details with regular updates, incident history, uptime statistics, and subscriber notifications via email or SMS. It should load quickly and be hosted separately from your main application.
What is the best status page example?
GitHub's status page (githubstatus.com) is widely considered one of the best examples. It features component-level status, detailed incident timelines, 90-day uptime graphs, and multiple notification channels. Stripe and Cloudflare also have excellent status pages.
How do I create a free status page?
You can create a free emergency status page instantly with tools like PerkyDash that require no signup. For permanent status pages, many monitoring tools include basic status pages in their free plans. Dedicated platforms like Atlassian Statuspage also offer limited free tiers.
Should a status page be hosted separately?
Yes. Your status page should be on different infrastructure than your main application. If they share hosting, both go down during an outage, making your status page useless exactly when you need it most.
How often should I update a status page during an incident?
Update every 15 to 30 minutes during an active incident, even if the update is simply that you're still investigating. Silence during an outage erodes trust faster than bad news.
Related Guides
Status Page Best Practices
How to create a status page that actually helps users during incidents.
CommunicationIncident Communication Guide
How to write incident updates that inform without causing panic.
DowntimeDowntime vs Degraded Performance
The difference between down and degraded, and why it matters for your status page.
EmergencyMy Site is Down — Now What?
Step-by-step plan for when things go wrong.