Status Page Examples: What the Best Status Pages Show

The best status page examples share four things: a short list of components named the way customers talk about them, a 90-day uptime history per component, several ways to subscribe before an incident happens, and a full archive of past incidents with timestamps. GitHub publishes 11 components with a 90-day uptime percentage on each. Cloudflare splits its page into services and then into individual data centers by region. Slack groups by product feature and reports uptime per quarter. None of them try to look perfect, and that is the point.

Everything below was read on those companies' live status pages in July 2026. They are worth studying because they are the pages your customers have already been trained by, so the closer your page is to these conventions, the less thinking anyone has to do at the worst possible moment.

What do the best status page examples have in common?

Four patterns show up on every serious status page, regardless of which vendor built it.

The component list is short and written in customer language, not architecture language. Nobody outside your team knows what the ingestion worker is. Every page below names things people actually use.

Historical uptime is visible without clicking. A page that only shows a green tick right now is asking to be trusted; a page showing 90 days of history is proving something.

Subscription options are prominent and plural. Email at minimum, and usually SMS, Slack, webhooks and RSS, because the whole value of the page is that people find it before they need it.

Past incidents are never deleted. The archive is what makes the page credible, and it is also what a prospect's procurement team reads before signing.

GitHub status page example

GitHub's page at githubstatus.com is the cleanest template to copy if you sell a developer product. It lists 11 components: Git Operations, Webhooks, API Requests, Issues, Pull Requests, Actions, Packages, Pages, Copilot, Codespaces, and Copilot AI Model Providers. Those are the names GitHub users would use in a support ticket, which is exactly the test a component name should pass.

Each component carries its own 90-day uptime graph with the percentage stated in plain text. Git Operations showed 99.99 percent uptime over the trailing 90 days when we looked, with a bar chart running from 90 days ago to today underneath it. Per-component history is more useful than a single site-wide number, because a customer who only uses the API does not care about your Pages availability.

The subscribe flow offers five routes: email with a one-time-code verification, SMS with country code and the same verification step, a one-click Slack integration, webhooks for a custom endpoint, and Atom and RSS feeds. The OTP step on email and SMS is a detail worth stealing, since it keeps the subscriber list clean.

Past incidents run chronologically with full update trails and timestamps, including pull request degradation on July 24, an Actions hosting disruption on July 22, and REST API availability problems across July 16 and 17. Each entry keeps every intermediate update rather than collapsing to a summary.

Cloudflare status page example

Cloudflare's page at cloudflarestatus.com solves a harder problem: a global network where a failure is usually regional rather than total. It handles that with two layers. The first is an alphabetical list of service components such as API, Workers and R2. The second is a geographic breakdown organized by continent, covering Africa, Asia, Europe, Latin America and the Caribbean, the Middle East, North America and Oceania, and then drilling into individual data center cities with their airport-style codes.

Each region carries its own header status, so the page can honestly say something like "Africa Partial Outage" while everything else stays operational, with individual cities marked Operational, Partial Outage, Under Maintenance or Degraded Performance underneath. If you serve customers in multiple regions, this is the model to follow, because a single global green tick is a lie when one region is dark.

Subscriptions run through the Cloudflare dashboard and support email, PagerDuty and webhooks, plus Atom and RSS feeds on the page itself. Scheduled maintenance windows are published in advance with specific timeframes, and past incidents show a clear status progression: Investigating, then Identified, then Monitoring, then Resolved. Those four states are close to an industry standard now, and using them means customers already know what each one implies about how far along you are.

Slack status page example

Slack's page at slack-status.com groups by product feature rather than by service: Login and SSO, Connectivity, Messaging, Files, Notifications, Huddles, Search, Apps and Integrations and APIs, Workspace and Org Administration, Workflows, and Canvases. Eleven components again, which is not a coincidence. Below about a dozen, a customer can scan the list; above it, they have to hunt.

Slack defines five status types explicitly on the page: No Issues, Maintenance, Notice, Incident and Outage. Publishing your own definitions is a small thing that prevents a lot of arguments, because it fixes in advance what counts as an incident versus a notice.

The uptime figure is reported per quarter rather than per rolling 90 days, and Slack explains the calculation directly: uptime is averaged across affected users, since during any given incident it is rare for every workspace to be affected. Stating the methodology is the honest move. An availability number without a definition is close to meaningless, and anyone who owes a customer an SLA will eventually be asked how theirs is computed.

Subscriptions are email, Atom and RSS, with notifications sent when Slack creates or updates an incident, and a calendar-based History view holds the archive.

What should a status page include?

Pulling the three examples together gives a concrete checklist.

How many components should a status page have?

Five to twelve is the working range, and all three examples above sit at the top of it. The failure mode in both directions is real. One component labeled "Platform" tells a customer nothing they did not already know, since they can see the site is broken. Forty components mapped to your internal services turns the page into a puzzle, and it also leaks your architecture to anyone who cares to look.

The test that works: write the list, then ask whether a customer could point at one line and say "that is the bit that is broken for me". If two lines could plausibly be the answer, merge them.

What uptime history should a status page show?

Ninety days is the convention, and it is the right default. It is long enough to be meaningful, short enough that one bad afternoon two years ago is not held against you forever, and it matches what most status page tools generate automatically. Show it per component rather than as one blended number, and state whether you are measuring availability of the service or availability weighted by affected users, the way Slack does.

The number has to come from somewhere defensible. If a human types it in, it is marketing. If it falls out of external uptime checks running on a fixed interval from several regions, it is evidence. That is the practical reason to run the page off monitoring rather than off a spreadsheet, and it is why we bundle the two.

What do most status pages get wrong?

Three mistakes account for nearly all of it.

The page is hosted inside the infrastructure it reports on. This is the big one. If your status page resolves through the same DNS, sits behind the same load balancer, or runs in the same cluster as production, it disappears in exactly the outage it exists to explain. All three examples above run on independent infrastructure at a separate domain.

Nobody updates it during a real incident. Components stay green while support drowns, usually because updating the page is a manual step that a stressed engineer skips. Automatic component flipping from confirmed checks fixes the availability half of this; incident templates fix the writing half.

The team learns about outages after customers do. By the time a page needs updating, people are usually already posting about it, and support inboxes are the slowest place to find out. Teams that care about this pair the page with monitoring on one side and something that tracks brand mentions across social and the web on the other, so the first signal is not an angry thread nobody saw for an hour.

How do you build a status page like these?

None of the pages above are bespoke. GitHub, Cloudflare and Slack all use hosted status page products, and the conventions they follow are what those products do by default. The build order is short: choose the five to twelve components a customer would name, decide whether you need a regional layer, connect them to real checks so the states change on their own, define your status levels in writing before your first incident, and put the page on a domain that has nothing to do with your production stack.

Our step-by-step walkthrough is in how to create a status page, and the vendor shortlist with verified pricing is in the status page software comparison. If you want the page and the monitoring underneath it on a single bill, Uptimehub includes a branded status page on your own domain in every plan, populated automatically by checks from six regions, so the 90-day history is real rather than typed in.