10 Status Page Examples: What Good Ones Do (and What Bad Ones Don't)
Real examples of status pages from companies that handle incidents well - with breakdowns of what makes each one effective, what they get wrong, and what you can steal for your own.
A status page is the first thing your customers check when they suspect something is wrong. Most status pages fail at that moment - they're outdated, vague, or harder to find than the outage itself.
This guide reviews 10 real status page examples, breaks down what each one does well (and what it doesn't), and ends with a practical checklist for building one that actually works.
What a Good Status Page Must Do
Before the examples, here's the bar any status page needs to clear:
| Requirement | Why it matters |
|---|---|
| Always shows current status | If the page looks the same during an outage as normal, customers won't trust it |
| Updates within minutes, not hours | Silence amplifies panic - a "we're investigating" post is better than nothing |
| Is findable without logging in | status.yourcompany.com, linked from your main site footer and help docs |
| Separates components | "API is down, dashboard is fine" is far more useful than "partial outage" |
| Shows incident history | Customers evaluating your reliability look at past incidents, not just current status |
| Lets users subscribe | Email or RSS so customers don't have to keep checking manually |
1. GitHub Status (githubstatus.com)
What they do well: GitHub's status page is the gold standard for developer tools. It separates every major service into discrete components - Git Operations, API Requests, Issues, Actions, Packages, Pages - so users can immediately see which part of the platform is affected without wading through prose.
The incident history goes back years and each entry includes a full timeline: when they detected the issue, when they started investigating, when they identified the root cause, and when they resolved it. The timestamps are specific to the minute.
What could be better: During major incidents, GitHub has occasionally been slow to update the status page while the outage was actively discussed on social media. The status page sometimes lags the Twitter conversation by 15–30 minutes - which erodes trust precisely when you need it most.
What to steal: The component breakdown model. Instead of one green/red dot for "GitHub," there are 12 separate components. When Actions is degraded, Git Operations stays green. That level of granularity is what separates useful status pages from decorative ones.
2. Cloudflare Status (cloudflarestatus.com)
What they do well: Cloudflare deals with regional incidents constantly - their network spans 300+ cities and failures are often localized to one or two regions. Their status page handles this well: incidents include a map showing affected locations, and the component list breaks down by service (CDN, DNS, Zero Trust, Workers, Images).
Cloudflare also maintains one of the most consistent update cadences in the industry. During major incidents, updates often come every 10–15 minutes, and they include technically honest language rather than PR hedging.
What could be better: The visual density is high. For non-technical stakeholders trying to understand "is the website down?", the page can feel overwhelming.
What to steal: Regional granularity. If your product uses CDN or multi-region infrastructure, show which regions are affected - not just "partial outage."
3. Stripe Status (status.stripe.com)
What they do well: Stripe's status page is a masterclass in component-level clarity for a payments platform. It separates API, Dashboard, Webhooks, and individual products (Radar, Connect, Billing, Terminal) - because a Radar degradation is very different from a Payments API outage.
Stripe also links directly from their developer documentation and API error messages to the status page. When a developer gets an unexpected 503, they can immediately check if it's a known issue without Googling.
What could be better: Stripe has a reputation for posting "all clear" slightly before some teams' issues are fully resolved. This may be a resolution verification challenge, but it leads to customers seeing green status while still experiencing errors.
What to steal: Link from your error messages and docs directly to your status page. If a developer hits a 500 error, the status page link should be one click away.
4. Atlassian Status (status.atlassian.com)
What they do well: Atlassian runs multiple products (Jira, Confluence, Trello, Bitbucket) and their status page handles product separation cleanly. You can view status by product or by region, which matters when an issue affects Jira Cloud US but not EU.
Their post-incident reports (PIRs) are particularly detailed - they publish root cause analyses within a few days of major incidents, which builds long-term trust even after a bad outage.
What could be better: Atlassian has taken criticism for being overly conservative with their status page - sometimes posting "investigating" when customers are already widely experiencing issues, or using "degraded performance" language when "significant outage" would be more accurate.
What to steal: Post-incident reports. Publishing a root cause analysis 48–72 hours after a major incident turns a bad moment into a trust-building one. It shows customers that you take reliability seriously.
5. Vercel Status (vercel-status.com)
What they do well: Vercel's status page reflects their product's architecture well: deployments, edge network, build system, and the dashboard are tracked separately. Given that Vercel serves developers who care deeply about deployment pipeline health, this granularity is exactly right.
The page loads fast (fitting, for Vercel) and the incident history is complete back to 2019, giving enterprise customers a multi-year reliability record to review during vendor evaluation.
What could be better: Component descriptions could be clearer for non-Vercel-native users. "Edge Network" and "Deployments" are meaningful to Vercel users, but a customer whose site is down just wants to know "is my website affected?"
What to steal: Maintain multi-year incident history. Customers evaluating your product for enterprise contracts will scroll back through 18–24 months. Gaps in history are a red flag.
6. Notion Status (status.notion.so)
What they do well: Notion keeps it simple. Their page lists four components (Web app, Desktop app, Mobile app, API) and the incident list is clean and chronological. The recent incident update times are always clearly visible.
Notion is also good at subscriber notifications - when they post an incident update, email subscribers get it within minutes, which reduces the "is anyone working on this?" anxiety among customers.
What could be better: The component list is probably too minimal. A Notion database sync failing is a very different incident than the entire web app being down, but both might appear as "Web app" degradation.
What to steal: Email subscription with fast delivery. The 30-minute lag between posting an update and customers receiving the email is the single most common complaint about status page notifications.
7. Linear Status (linearstatus.com)
What they do well: Linear's status page is a good example of matching the status page design to the brand. It's clean, minimal, and fast - consistent with the product itself. The component list covers the right things for a project management tool: web app, mobile apps, API, sync, and webhooks.
Linear is notably good at incident communication tone - their updates are written by engineers, not by marketing, and it shows. The language is direct and technically honest.
What could be better: The public incident history is shorter than competitors. For teams evaluating Linear for enterprise use, a longer history would help.
What to steal: Engineering-voice incident updates. Updates that say "we've identified a deadlock in the sync worker" are far more credible than "we're experiencing performance issues." Technical honesty builds trust with technical users.
8. Fly.io Status (status.fly.io)
What they do well: Fly.io is a distributed platform where regional failures are common and expected. Their status page handles this by listing individual regions (ams, bom, cdg, den, dfw, ewr, fra, hkg, iad, lax, lhr, maa, mad, mia, nrt, ord, sea, sin, sjc, syd, yul, yyz) and their current health.
This is the right model for any infrastructure provider with genuine geographic distribution - customers can immediately see "ord is degraded, everything else is fine" rather than getting a vague "partial outage" message.
What could be better: The sheer number of regions makes the default view dense. A map-based view (like Cloudflare's) would make geographic issues easier to interpret at a glance.
What to steal: If you have multiple regions or datacenters, list them individually. "US-East is degraded" is 10x more useful than "some customers may experience issues."
9. Supabase Status (status.supabase.com)
What they do well: Supabase lists their components in a way that matches how developers think about their product: Database, Auth, Storage, Realtime, Edge Functions, and Dashboard are all tracked separately. A Realtime issue doesn't affect Storage, and the status page makes that clear.
Supabase also does something few status pages bother with: they link from their status page directly to their incident communication on their blog or Discord when there's a major event, so customers can follow the full conversation rather than just reading terse status updates.
What could be better: Update frequency during incidents can be slow. The worst status pages are ones that go dark during an active outage, and Supabase has had occasional long gaps between updates.
What to steal: Link out to richer incident communication. A status page update of "investigating" is less useful than "investigating - follow our Discord for real-time updates." Give customers a place to go.
10. Shopify Status (shopifystatus.com)
What they do well: Shopify runs critical e-commerce infrastructure where downtime has direct, immediate revenue impact for merchants. Their status page reflects this urgency: component separation is detailed (Online Store, Checkout, Admin, API, Shopify Payments, Shipping, Point of Sale), and incident descriptions are explicit about merchant impact.
For major incidents, Shopify maintains an active Twitter presence alongside the status page, which gives real-time context for merchants who are already on social media when something goes wrong.
What could be better: Shopify's status page occasionally understates severity during incidents - "degraded performance" when merchants are reporting checkout failures is a trust problem. Customers accept outages; they don't accept being misled about severity.
What to steal: Make the revenue impact explicit. "Checkout is affected" hits differently than "some API requests may fail." Speak the customer's language.
Common Patterns Across Good Status Pages
After reviewing dozens of status pages, these patterns separate the ones that build trust from the ones that erode it:
What good status pages do
✅ Component-level granularity - not one dot for the whole product
✅ Timestamped updates every 10–30 minutes during incidents
✅ Published at status.yourcompany.com - a clean, memorable URL
✅ Linked from footer, error pages, and docs
✅ Email and RSS subscription with fast delivery
✅ Complete incident history, years back
✅ Post-incident reports for major outages
✅ Technical, honest language written by engineers
What bad status pages do
❌ Stay green during known outages - customers know before the page does
❌ Post "investigating" and then go silent for hours
❌ Use vague language - "some customers may experience issues" for a full outage
❌ Require login to view
❌ Have no subscription mechanism
❌ Show only current status with no history
❌ Are styled completely differently from the main product - makes them look like an afterthought
Status Page Checklist
Before you publish, check these:
- Accessible at status.yourdomain.com
- No login required
- Components match your actual product architecture (not just "API" and "Dashboard")
- Current status updates automatically from your monitoring tool - not manually
- Historical incidents visible for at least 12 months
- Email and/or RSS subscription available
- Linked from main site footer, help center, and error pages
- Incident update process defined: who posts, how often, what format
- Post-incident report process defined for major incidents
Building Your Own
A status page is most effective when it's connected directly to your monitoring system - so status updates happen automatically when your monitors detect an issue, not after someone manually logs in and changes a dropdown.
Tools that handle this well include Vantaj (status pages included on all plans, including free, and automatically updated when monitors detect failures), Better Stack, and Atlassian Statuspage for enterprise needs.
The most expensive status page failure isn't a technical one - it's an organizational one: a real outage happening while the status page stays green because no one is responsible for updating it.