Status Page Examples: Six Public Pages, Graded
Six real status page examples judged on their component lists and machine-readable endpoints rather than their design, with what each one is worth copying.
Most status page examples get graded on their design, which is the least interesting thing about them. What separates a page that calms customers from one that annoys them is the component list, the honesty of the incident writing, and whether a machine can read it. Six public pages below, judged on those three.
The three jobs a status page has
It answers "is it you or me" before someone opens a ticket. It gives an affected customer a place to subscribe so they stop refreshing. It leaves a record afterwards that a prospect's procurement team can read.
Design serves those jobs or it gets in the way. A gorgeous page with one component called "Platform" fails the first job, because nobody learns anything from a green dot next to a word that covers everything you sell.
Six status page examples, and what each one teaches
We tested every page in this table on 23 September 2026 by requesting its component list and its JSON status endpoint. The results below come from that check rather than from a screenshot.
| Page | Built on | Component style | Worth stealing |
|---|---|---|---|
| GitHub | Statuspage | Named after user actions | Component names a developer already uses |
| Discord | Statuspage | Client, region and subsystem | Declares a third-party dependency openly |
| Cloudflare | Statuspage | Per data center | Granularity that matches how it fails |
| Netlify | Statuspage | Own surfaces plus upstreams | Names the dependencies it cannot control |
| Stripe | Custom build | No public JSON endpoint | Shows what leaving the template costs |
| Slack | Custom build | No public JSON endpoint | Full control of wording and layout |
Four of the six status page examples here run on Atlassian's Statuspage. Two built their own, which is a real signal about how much a payments company and a messaging company care about controlling that page during a bad day.
GitHub: name components after what people do
Its component list reads Git Operations, API Requests, Webhooks, Issues, Pull Requests, Actions, Packages, Pages, Codespaces and Copilot. Not one of those is an internal service name.
That matters because a user arriving mid-incident is not debugging your architecture. They are asking whether the thing they were doing is broken. A developer who cannot push knows to look at Git Operations, and never has to guess which backend owns that path.
The counter-example is a page whose components are called API, Global and Platform. Technically accurate, useless to the person reading it. One of the largest hosting providers on our list labels almost every component "Global", which tells a customer nothing about their own region.
Discord: model the axis your users fail along
Discord splits its components three ways at once. By client, with separate entries for Desktop, iOS, Android and Web. By region, with entries such as Atlanta, Brazil, Rotterdam and Hong Kong. By subsystem, with API, Gateway, Media Proxy and Push Notifications.
Real outages there are usually partial, hitting one region or one client build, so the component model matches the failure model. A single green or red light would misrepresent almost every incident it has.
It also lists a component for its Cloudflare dependency. Naming an upstream provider in public takes some nerve, and it saves an enormous amount of support time when that provider is the one having the bad day.
Cloudflare and Netlify: granularity, and naming your upstreams
Cloudflare's page carried 480 components when we pulled the list. Most are a single data center with its airport code attached, from Amsterdam to Accra to Anchorage. That looks absurd until you remember how the network fails. Outages there are usually one city, and a customer in Auckland wants the Auckland line rather than a global average.
Netlify takes the opposite approach with around 40 components, and a striking share of them belong to other companies. Its list includes GitHub Git Operations, GitHub Webhooks, Bitbucket SSH, the npm registry and NS1's API, alongside its own build pipeline and edge network.
That is the most copyable idea on this page. When a build fails because a package registry is down, the page says so immediately, and support answers no tickets at all. Listing the dependencies you cannot control is cheaper than explaining them one customer at a time.
Should you build your own or use a template?
Statuspage is the default for good reasons: subscriptions, scheduled maintenance and incident history all arrive working. Stripe and Slack still built their own. Neither answered the standard JSON endpoint when we checked, so anyone automating against them has to scrape or use a separate feed.
There is an obvious trap in that choice. A hand-rolled status page hosted in the same infrastructure as the product goes down with it, which is the one moment it needs to be up. Whatever you pick, host it somewhere your main stack cannot take with it.
The machine-readable half nobody mentions
Every Statuspage-hosted example answers a request to /api/v2/status.json with a current indicator, and /api/v2/components.json returns the full component list. When we ran the check, five of the pages reported an indicator of "none" and Cloudflare reported "minor".
That endpoint is the most underused feature in this whole category. You can poll a vendor's status JSON, match it against your own alerts, and stop paging your team for an outage that belongs to somebody else. Most incident tooling will consume it directly.
Your own page should offer the same courtesy. Publish an RSS feed and a JSON endpoint, because the customers who care most are the ones who want to automate around you.
Setting one up without lying on it
The status page examples that age well share one property: something independent decides the colour of the lights. If a human updates it by hand, it is a blog with a green dot, and it will be wrong during exactly the incident that matters.
Wire components to real checks, keep the page off your own infrastructure, and separate announced work from unannounced failure so the history stays meaningful. That last rule belongs in your maintenance window policy rather than in a decision made at 2am.
Basic status pages on a subdomain are included on the free plan as of September 2026, with a custom domain on Individual and white-label on Enterprise. Whoever writes the updates should work from a prepared template, which incident communication covers in detail.
Common mistakes
One component for the entire product. It answers no question a customer has. Split by the surfaces people actually use, the way GitHub does.
Updating by hand only. The first update during a real outage arrives twenty minutes late, every time. Drive the lights from checks and let a human add the prose.
Hosting it on the infrastructure it reports on. When the region goes, so does the page. Keep them apart.
Quietly editing history. The record is the reason a prospect trusts you. Correct an entry openly rather than deleting it, and keep the numbers consistent with how you measure downtime.
The best status page examples are boring on a good day and specific on a bad one. Name components after user actions and write incidents in plain language. Publish a JSON endpoint for anyone automating, and drive the lights from checks rather than from a person with a browser tab. Build that and the page starts deflecting tickets instead of generating them. You can start free and have a basic one published this afternoon.
FAQ
A public page that shows whether each part of a service is working, records incidents while they happen, and lets customers subscribe to updates. Its main job is answering the question people ask before they open a support ticket, which is whether the problem is yours or theirs. The historical record it leaves behind is what a prospect reads later.
GitHub is the best example of component naming, with entries like Git Operations, Actions and Pages that match what people do rather than internal service names. Discord models its components by client, region and subsystem because its outages are usually partial. Stripe and Slack show what a custom-built page buys you in exchange for maintaining one.
Components named after user-facing surfaces, current status for each, an incident feed written in plain language, scheduled maintenance announced before it starts, a subscription option, and a history that is never quietly edited. Add a JSON endpoint and an RSS feed so customers who want to automate around your incidents can do so.
Not on the same infrastructure as the product it reports on, because it will go down at the exact moment it is needed. Hosted status pages from a monitoring provider avoid that by design. Building your own is worth it only when you need tight control of wording and layout, which is why Stripe and Slack did it.
Related reading
- Incident Communication: Templates and a Cadence - Incident communication works when the first update ships in minutes. Here are the templates, the cadence by severity, and who posts each one.
- Maintenance Window: Plan One Without False Alerts - A maintenance window is announced downtime you control. Here is how to size it, suppress the right alerts, and keep the data you will need later.