Status page examples: 40 real status pages, the status page software behind each one, and what their design gets right
Every other list of status page examples is somebody's taste. This one is a measurement. We fetched all 40 pages on 31 August 2026, recorded what software serves them, how many components each one lists and what a machine can read from them, and the results are below. Score your own page against the same four tests first.
Status page scorecard
LiveTick what your own status page already does. Each row shows how many of the 40 pages we measured do the same thing.
The sample average is 2.3 of 4. Nothing you tick leaves your browser.
What software do companies use for their status page?
The 40 status pages checked here run on three things: 23 use Atlassian Statuspage, 11 are built in house, and 6 run on incident.io. Component counts range from 4 on Plaid to 478 on Cloudflare, with a median of 25. The number most people expect to find is usually missing: only 12 of the 40 publish any uptime history at all, and every one of those 12 is an Atlassian Statuspage. Sixteen serve the page from a different registrable domain than the product itself, which is what keeps it reachable when the product DNS or CDN is the thing that broke.
Everything on this page was measured on 31 August 2026 by fetching each live page and, separately, requesting a status API at the same origin. Nothing here is copied from another roundup. Where a figure could not be read we have said so rather than guessed, which is why the components column is blank for eleven of the forty.
The short version
- Market share: Statuspage 23, in house 11, incident.io 6.
- Components: median 25, from 4 at Plaid to 478 at Cloudflare.
- Uptime published: 12 of 40, all of them Atlassian pages.
- Best single model: GitHub, which passes all four tests.
The status page software census, 40 pages, measured 31 August 2026
Three platforms account for all forty pages. There is no long tail here at all, which is itself worth knowing before you shortlist: the market you are shopping in is far more concentrated than the number of vendors selling into it suggests.
| Platform | Pages | Share | Who |
|---|---|---|---|
| Atlassian Statuspage | 23 | 58% | GitHub, Cloudflare, Twilio, Discord, Zoom, Vercel, Sentry, Netlify, Reddit, Coinbase, Supabase, Render and eleven more. |
| Custom / in house | 11 | 28% | AWS, Google Cloud, Salesforce, Stripe, Slack, GitLab, Heroku, Zendesk, Okta, Fastly, PagerDuty. |
| incident.io | 6 | 15% | OpenAI, Notion, Docker, Linear, Plaid, Intercom. |
The in house group is not a random eleven. It is mostly the companies whose own infrastructure is the product: AWS, Google Cloud, Salesforce, Fastly, Cloudflare being the notable exception. If your business is selling compute, telling customers it is down through somebody else's SaaS is a hard conversation internally. For everyone else, the build decision is discussed further down.
Atlassian's status API has quietly become the standard its competitors implement
Twenty nine of the forty pages answer a request to /api/v2/summary.json with a valid JSON document listing every component and its state. That endpoint is Atlassian Statuspage's public API. Only twenty three of the forty are Atlassian pages.
The six that answer it and are not Atlassian
OpenAI, Notion, Docker, Linear, Plaid and Intercom all run on incident.io, and all six serve a working Statuspage v2 summary endpoint. Requesting it from status.openai.com returns a document with the page name, an overall status indicator and 25 components, in exactly the shape Atlassian documents. incident.io implements the competitor's API so that everything already pointed at Statuspage keeps working after a migration.
Why this matters if you are building anything
Two practical consequences. First, if you poll vendor status pages to feed your own dashboard, one client covers 29 of these 40 without special cases. Second, you cannot identify a page's platform from the API, and any tool that tries will report six incident.io pages as Atlassian customers. We nearly published that mistake ourselves, and it took reading the asset paths in the HTML to catch it.
The eleven with no such API are the in house builds. For those, an RSS or Atom feed is usually the only machine readable surface, and five of them do not even offer that reliably. If you want to be told when a vendor breaks rather than find out from a customer, that gap is the whole problem: our website down checker exists partly because vendor status pages are so often the last thing to change.
Only 12 of the 40 publish an uptime figure, and all 12 are on the same platform
The single most requested thing on a status page is the one most of them leave out. GitHub, Anthropic, Twilio, Discord, npm, Vercel, Asana, Render, Supabase, Reddit, Sentry and Netlify publish 90 day uptime history. That is 12 of 40, or 30 percent. Every one of the twelve is an Atlassian Statuspage with the uptime showcase enabled, which means 11 Atlassian customers in this sample pay for the feature and leave it switched off.
Atlassian Statuspage
12 of 23
Just over half of the pages that have the feature available actually turn it on.
incident.io
0 of 6
None of the six incident.io pages in the sample shows a historical uptime figure.
Built in house
0 of 11
Not one of the custom builds publishes uptime history, including all three hyperscalers.
There is an obvious reason for the reluctance and it is worth naming honestly: a published uptime number is a number a customer can hold you to. The counter argument is that a page which only ever shows green tells a prospect nothing, while 99.95 percent with three documented incidents and clean write ups reads as a team that knows what it is doing. If you want to work out what a given percentage costs you in real minutes, the uptime calculator converts between the two, and 99.99 percent uptime explains what that particular target actually commits you to.
Five of these pages are invisible to anything that is not a browser
Stripe returns 892 bytes of HTML. Zendesk returns 1,314. Salesforce returns 1,507, the AWS Health Dashboard 3,382 and Heroku 4,925. Everything a human reads on those five pages is assembled in the browser afterwards. All five are custom builds, and the same five have no status API.
| Status page | HTML served | Status API | What a monitor sees |
|---|---|---|---|
| Stripe | 892 B | None | An empty shell. No component names, no incident text. |
| Zendesk | 1,314 B | None | Same. Keyword matching on the HTML will never fire. |
| Salesforce | 1,507 B | None | Trust status is a full application, not a document. |
| AWS Health Dashboard | 3,382 B | None | The old RSS style feeds are not on this document. |
| Heroku | 4,925 B | None | Rendered client side from a private endpoint. |
If you are building anything that watches vendor status, this is the practical takeaway: 35 of the 40 can be read with a plain HTTP request and 5 cannot be read at all without running a browser. And if you are building your own status page, note that a client rendered page is also a page that fails to render when your CDN or your JavaScript bundle host is the thing having the incident. A status page is the one page on your estate that should be boring server rendered HTML.
How people actually subscribe, and the one Atlassian page that does not offer a feed
A status page nobody has subscribed to only works for people who already suspect something is wrong, which is the group that needs it least. The measurable version of that is whether the page declares an RSS or Atom feed in its HTML head, because that is the subscription channel that works for machines and for the people who never fill in an email box. Twenty nine of the forty declare one.
The eleven with no declared feed
Slack, Cloudflare, Heroku, Zendesk, GitLab, Google Cloud, AWS, Salesforce, Fastly, Okta and PagerDuty. Ten of the eleven are custom builds, which is the expected result. Cloudflare is the exception and the interesting one: it runs Atlassian Statuspage, where a feed is standard, on a heavily stripped template that serves only 39 KB of HTML for 478 components. Something in that customization dropped the feed link.
Why the incident archive matters more than the current light
The green light answers one question for one minute. The archive answers the question a prospect in a security review is actually asking, which is how you behave when things break. Every hosted page in this sample keeps a dated incident history with per update timestamps, and the good ones write each update to say what is affected, what is being done and when the next update lands. That is the one thing on this page we could not measure, and it is probably the most important.
Worth noting that a declared feed and a readable page are not the same test. Stripe declares an Atom feed in a document that is otherwise 892 bytes of empty shell, so the feed is the only part of that page a machine can use. If you are subscribing to a vendor rather than publishing your own page, check the feed first and the page second.
How many components to list, according to 20 companies who decided
This is the design question people actually get stuck on. The measured answer across the pages that expose a component list: the median is 25 and the range is 4 to 478, a spread of 120 times. The split is not about company size. It is about whether a customer can tell which component they are using.
| Status page | Components | How it is split |
|---|---|---|
| Cloudflare | 478 | Every edge location and product line listed separately, which is why the page is 39 KB of HTML and a wall of rows. |
| Zoom | 335 | Split by product and by region. Useful if you know which region you are in, overwhelming if you do not. |
| DigitalOcean | 256 | One row per product per datacenter region. The regional split is the point for infrastructure buyers. |
| Twilio | 191 | Per channel and per country, because SMS deliverability genuinely varies that way. |
| Coinbase | 174 | Per asset and per API surface. |
| Vercel | 64 | Build, edge, functions and per region. |
| Render | 62 | Per service type and per region. |
| Sentry | 47 | Ingestion split from the dashboard, which is the distinction their customers care about. |
| Netlify | 40 | Build, edge and the API kept apart. |
| Datadog | 39 | Split by region first, because a Datadog customer lives in exactly one of them. |
| Discord | 33 | By feature and by voice region. |
| Supabase | 28 | Per product, database, auth, storage, edge functions. |
| OpenAI | 25 | Per model family and per API surface. |
| Notion | 19 | Web, mobile, API, search, integrations. |
| Figma | 17 | Editor, file storage, comments, plugins. |
| GitHub | 12 | Twelve rows for the whole of GitHub, and it reads far better than 478. |
| Anthropic | 6 | One row per model surface plus the console. |
| npm | 6 | Registry, search, website, publishing. |
| Linear | 6 | App, API, integrations, sync. |
| Plaid | 4 | The tightest list in the sample. Four rows, no ambiguity. |
List a lot when the customer knows their region
DigitalOcean at 256, Datadog at 39 and Zoom at 335 all split by region, and that is correct for them. A DigitalOcean customer lives in one datacenter and does not care what NYC3 is doing if they are in FRA1. The rule is simple: split by a dimension the reader can identify themselves in. Region and product line pass that test. Internal service names do not.
List a few when everyone uses everything
GitHub covers the whole of GitHub in 12 rows and Plaid in 4. Both are correct too, because every customer touches most of the surface. If a reader has to scroll to find their row, the page has failed at the one job it has during an incident, which is answering "is it me" in under five seconds. Start at ten and add a row only when someone asks for it.
All 40 status page examples, with what each one is running
Alphabetical. Every URL is the effective address after redirects, which is why Intercom appears as finstatus.com and Slack as slack-status.com. Components is blank where the page serves no machine readable list.
| Company | Status page | Software | Components | Uptime shown | Status API | Hosting |
|---|---|---|---|---|---|---|
| Anthropic | status.claude.com | Atlassian Statuspage | 6 | Yes | Yes | Separate domain |
| Asana | status.asana.com | Atlassian Statuspage | 35 | Yes | Yes | Subdomain |
| Atlassian | status.atlassian.com | Atlassian Statuspage | 0 | No | Yes | Subdomain |
| AWS | health.aws.amazon.com | Custom / in house | No | No | Subdomain | |
| Cloudflare | www.cloudflarestatus.com | Atlassian Statuspage | 478 | No | Yes | Separate domain |
| Coinbase | status.coinbase.com | Atlassian Statuspage | 174 | No | Yes | Subdomain |
| Datadog | status.datadoghq.com | Atlassian Statuspage | 39 | No | Yes | Subdomain |
| DigitalOcean | status.digitalocean.com | Atlassian Statuspage | 256 | No | Yes | Subdomain |
| Discord | discordstatus.com | Atlassian Statuspage | 33 | Yes | Yes | Separate domain |
| Docker | www.dockerstatus.com | incident.io | 21 | No | Yes | Separate domain |
| Dropbox | status.dropbox.com | Atlassian Statuspage | 12 | No | Yes | Subdomain |
| Fastly | www.fastlystatus.com | Custom / in house | No | No | Separate domain | |
| Figma | status.figma.com | Atlassian Statuspage | 17 | No | Yes | Subdomain |
| GitHub | www.githubstatus.com | Atlassian Statuspage | 12 | Yes | Yes | Separate domain |
| GitLab | status.gitlab.com | Custom / in house | No | No | Subdomain | |
| Google Cloud | status.cloud.google.com | Custom / in house | No | No | Subdomain | |
| Heroku | status.heroku.com | Custom / in house | No | No | Subdomain | |
| HubSpot | status.hubspot.com | Atlassian Statuspage | 11 | No | Yes | Subdomain |
| Intercom | www.finstatus.com | incident.io | 0 | No | Yes | Separate domain |
| Linear | linearstatus.com | incident.io | 6 | No | Yes | Separate domain |
| MongoDB | status.mongodb.com | Atlassian Statuspage | 9 | No | Yes | Subdomain |
| Netlify | www.netlifystatus.com | Atlassian Statuspage | 40 | Yes | Yes | Separate domain |
| Notion | www.notion-status.com | incident.io | 19 | No | Yes | Separate domain |
| npm | status.npmjs.org | Atlassian Statuspage | 6 | Yes | Yes | Separate domain |
| Okta | status.okta.com | Custom / in house | No | No | Subdomain | |
| OpenAI | status.openai.com | incident.io | 25 | No | Yes | Subdomain |
| PagerDuty | status.pagerduty.com | Custom / in house | No | No | Subdomain | |
| Plaid | status.plaid.com | incident.io | 4 | No | Yes | Subdomain |
| www.redditstatus.com | Atlassian Statuspage | 12 | Yes | Yes | Separate domain | |
| Render | status.render.com | Atlassian Statuspage | 62 | Yes | Yes | Subdomain |
| Salesforce | status.salesforce.com | Custom / in house | No | No | Subdomain | |
| Sentry | status.sentry.io | Atlassian Statuspage | 47 | Yes | Yes | Subdomain |
| Shopify | www.shopifystatus.com | Atlassian Statuspage | 9 | No | Yes | Separate domain |
| Slack | slack-status.com | Custom / in house | No | No | Separate domain | |
| Stripe | status.stripe.com | Custom / in house | No | No | Subdomain | |
| Supabase | status.supabase.com | Atlassian Statuspage | 28 | Yes | Yes | Subdomain |
| Twilio | status.twilio.com | Atlassian Statuspage | 191 | Yes | Yes | Subdomain |
| Vercel | www.vercel-status.com | Atlassian Statuspage | 64 | Yes | Yes | Separate domain |
| Zendesk | status.zendesk.com | Custom / in house | No | No | Subdomain | |
| Zoom | www.zoomstatus.com | Atlassian Statuspage | 335 | Yes | Yes | Separate domain |
Two rows are worth a note. Atlassian's own status page and Intercom's both return an empty components array through the API, so the count reads 0 rather than being unavailable. And Anthropic's page sits on status.claude.com, a domain named after the product rather than the company, which is the same separation strategy as githubstatus.com by a different route.
Four things worth copying, ranked by how rare they are
Every item here is something we could count, so the rarity figure is real rather than an opinion about which page looks nicer.
Hosted on a domain separate from the product
16/40A status page on status.yourapp.com dies with your DNS. Sixteen of the forty use a separate registrable domain, githubstatus.com rather than status.github.com, so a bad DNS change or a CDN failure cannot take both down together.
Publishes uptime history
12/40Only twelve of the forty show any historical uptime figure, and all twelve are Atlassian Statuspage customers with the uptime showcase switched on. Every incident.io page and every in house page in the sample publishes none.
Serves a machine readable status API
29/40Twenty nine expose a JSON endpoint that any monitor can poll. That is what lets your own tooling react to a vendor outage instead of waiting for a human to notice.
Readable with JavaScript disabled
35/40Five pages return under 5 KB of HTML and render entirely in the browser. A plain HTTP check or an RSS reader pointed at those sees nothing at all.
How the 40 pages score on these four tests
Seven pages pass all four: GitHub, Anthropic, Discord, npm, Vercel, Reddit and Netlify. Five pass none, and those five are the client rendered custom builds. The average is 2.3 of 4, which is the bar the scorecard at the top of this page measures you against.
| Score | Pages | Who |
|---|---|---|
| 4 of 4 | 7 | GitHub, Anthropic, Discord, npm, Vercel, Reddit, Netlify |
| 3 of 4 | 12 | Cloudflare, Zoom, Twilio, Notion, Shopify, Linear, Asana, Render, Supabase, Docker, Sentry, Intercom |
| 2 of 4 | 12 | Slack, OpenAI, Dropbox, Atlassian, DigitalOcean, Datadog, Figma, HubSpot, MongoDB, Coinbase, Plaid, Fastly |
| 1 of 4 | 4 | GitLab, Google Cloud, Okta, PagerDuty |
| 0 of 4 | 5 | Stripe, Zendesk, Salesforce, AWS, Heroku |
The fifth thing, which we could not measure and will not pretend we did, is the writing. During an incident the difference between a page people trust and a page people rage about is whether the update says what is affected, what is being done and when the next update lands. A template helps more than instinct here, and the incident postmortem template covers the write up that follows.
Should you build one or buy one
Eleven of these forty companies built their own. Ten of the eleven either sell infrastructure themselves or are large enough to run a dedicated status team. The measurements suggest the build is harder to keep good than it looks: none of the eleven publishes uptime history, none serves a standard status API, and five of them do not render without JavaScript.
Build it when
Your product is infrastructure and telling customers you are down through a third party SaaS is politically impossible, or you have regulatory reasons the page must live under your control. Budget for someone to own it, because an out of date status page is worse than none.
Buy a dedicated tool when
Incident communication is a real workflow with several people in it, you need audience specific pages, or you already run incident management somewhere and want the page wired into it. That is what Atlassian Statuspage and incident.io are for, and 29 of these 40 pages took that route.
Take the bundled one when
You are buying uptime monitoring anyway. The monitors that decide whether a component is up are the same monitors you were going to pay for, so a status page fed by them is close to free. This is the common case for small teams and agencies and it is the route we sell.
Being straight about where we fit: Uptimehub is the third option. A branded status page on your own domain is included from $9 a month, fed directly by the checks that are already running, which is why it passes the separate domain and published uptime tests without extra work. What we do not do is the incident management workflow that Atlassian and incident.io build their products around. If your status page needs approval chains and audience segmentation, buy one of those. The status page software comparison sets all of them side by side, and status page pricing covers what each one actually charges.
Status page questions, answered from the measurements above
What software do companies use for their status page?
Atlassian Statuspage is still the default. Of 40 well known status pages checked on 31 August 2026, 23 run on Statuspage, 11 are built in house and 6 run on incident.io. No other hosted vendor appeared in the sample at all. The in house group is almost entirely the largest infrastructure providers, AWS, Google Cloud and Salesforce among them, who have their own reasons for not depending on a third party.
What is a good example of a status page?
GitHub is the one worth copying first. It runs on a separate domain, githubstatus.com, so it survives a GitHub DNS failure. It breaks the service into twelve components rather than 478. It publishes 90 day uptime history, which only 12 of the 40 pages checked do. And it serves a JSON API any monitor can poll. Four things, all measurable, and most pages in the sample get two of them.
What should a status page include?
A current state for each component your customers can name, an incident history with timestamps, a way to subscribe, and historical uptime. The last one is the one teams skip: 28 of the 40 pages checked publish no uptime figure at all. A page showing 99.95 percent with documented incidents is more credible than one that only ever shows a green light, because the green light tells a reader nothing about the last six months.
Should a status page be on a separate domain?
Yes, and 16 of the 40 pages checked do it. If your status page lives at status.yourapp.com it shares a DNS zone, and often a CDN, with the thing it is supposed to report on. GitHub, Cloudflare, Discord, Slack, Reddit, Zoom, Netlify, Shopify and Vercel all register a second domain for this. The page also needs to be hosted somewhere unrelated to your own infrastructure, which is the part a separate domain alone does not solve.
How much does a status page cost?
Atlassian Statuspage starts at a published monthly price per page and rises steeply once you want a custom domain, more subscribers or audience specific pages. Several uptime monitoring tools include a branded status page in the plan you are already paying for, which is usually the cheaper route if you also need monitoring. Uptimehub includes one on a custom domain from $9 a month. The full vendor by vendor breakdown is on the status page pricing page.
Can I build my own status page instead of buying one?
You can, and 11 of the 40 companies checked did. The catch shows up in the measurements: 5 of those 11 return under 5 KB of HTML and render entirely in JavaScript, so nothing can read them automatically, and not one of the 11 publishes uptime history. Building the page is a weekend. Keeping it accurate during an incident, on infrastructure that is not the infrastructure that just failed, is the actual cost.
Do status pages show uptime percentage?
Most do not. Twelve of the 40 pages checked show a historical uptime figure and all twelve are Atlassian Statuspage customers who enabled the uptime showcase. Every in house page in the sample and every incident.io page publishes none. If you want a vendor uptime number for an SLA review, expect to compute it yourself from their incident history rather than read it off the page.
How do I monitor another company status page automatically?
Request /api/v2/summary.json at the status page origin. Twenty nine of the 40 pages checked answer it with a JSON document listing every component and its current state, and that includes all six incident.io pages even though incident.io is not Atlassian. For the eleven with no API, an RSS or Atom feed is the next best option, and for the five that render only in JavaScript there is no reliable automated read at all.
Keep going on status pages
Status page software
Every vendor side by side, with what is included rather than what is advertised.
Status page pricing
What a hosted status page costs once custom domains and subscribers are added.
Uptime calculator
Turn a percentage into the minutes of downtime it actually allows per month.
Is my website down
Check a site from outside your own network before you trust anybody's status page.
SSL certificate checker
The expiry that takes a status page down along with everything else.
Uptimehub pricing
Four plans, published in full, with a branded status page in every one of them.
A status page fed by real checks
Your own domain, your branding, and uptime history published automatically from the monitors that are already running. Included from $9 a month, on every plan, with no per page charge.