Status Page Design: What Makes a Great Public Status Page

Most status pages are an afterthought. A developer spins one up, points it at a single "Website" monitor, and never touches it again. It shows green. Users don't know where to find it. During an incident, nobody updates it.

A good status page is designed from the user's perspective: someone who is panicking slightly, checking on their phone, trying to quickly answer the question "is it just me, or is the service actually down?" Every design decision should serve that person.

---

The anatomy of a great status page

1. A clear current status at the top

The most important piece of information — is everything working right now? — should be visible without scrolling. A large, colored status indicator with plain English text: "All systems operational" in green, or "Partial outage" in amber, or "Major incident in progress" in red.

Bad status pages bury this. The user has to scroll past a company logo, navigation, and multiple components before they see the aggregate status. During an outage, users shouldn't have to hunt for the answer.

2. Component breakdown, not a single dot

A single "Website: operational" monitor tells users almost nothing. A well-structured status page breaks the service into meaningful components:

• API — the backend
• Dashboard — the frontend users log into
• Authentication — login specifically, since this is high-impact
• Email delivery — notifications and transactional email
• Webhooks / integrations — if you have them

This specificity does two things: it helps affected users understand whether their use case is impacted, and it demonstrates that you actually know your own system. "API is degraded, dashboard is unaffected" is meaningful. "Some services are experiencing issues" is not.

3. 90-day uptime history

The row of colored bars showing uptime history over the past 90 days is one of the most important trust signals a status page can have. Here's why: a status page that only shows the current moment is easy to fake or manipulate. A 90-day history is harder to dismiss — it's a record.

A page with a few incidents in the past 90 days, each handled and resolved, is more trustworthy than a page showing a perfect green record with no history. The former demonstrates that the team monitors, responds, and communicates. The latter is suspicious.

PingBase status pages show 90-day uptime history bars by default, on all plans.

4. Real-time updates without manual refresh

During an incident, users shouldn't have to manually refresh the page to see updates. Status pages should reflect the current state automatically. This requires the page to be served from infrastructure independent of your main application — if your app is down, the status page still needs to load.

PingBase status pages are served from Cloudflare's edge network. If your origin server is down, the status page still loads in under 100ms from a CDN node near your user.

5. An incident timeline during active incidents

When something is wrong, users want to see that you know about it and are working on it. An incident timeline shows timestamped updates in reverse chronological order — the most recent at the top.

The timeline should show the progression: "Investigating → Identified → Monitoring → Resolved." Each state change should have a plain-English update describing what's happening. This is the piece of the status page that does the most work to maintain user trust during a difficult moment.

---

What bad status pages do wrong

Having seen a lot of status pages, a few failure patterns appear repeatedly:

The permanently green page

A status page that shows 100% uptime for months and never has a single incident is suspicious. No service is that perfect. What it usually means is that the monitoring isn't sensitive enough to catch degradation, or the page isn't being updated during incidents. Users notice this and trust it less, not more.

The stale incident

An incident was created three days ago, the last update was "Investigating," and the monitor shows green. This means someone forgot to close the incident. Users visiting the status page see an unresolved incident and don't know if the service is working or not. This is worse than no status page.

Fix: when a monitor recovers, automatically transition the incident to "Resolved" if it wasn't manually closed. PingBase does this.

Ads on the status page

Some monitoring tools (UptimeRobot's free plan, notably) show ads from competitor services on your status page. During an incident, your users are already stressed — serving them ads for your competitors at that moment is a trust-destroying experience. This is the single thing that drove most PingBase users away from UptimeRobot.

PingBase never shows ads on any status page, on any plan.

Slow to load during incidents

Status pages need to be fast precisely when everything else is slow. If your status page is hosted on the same servers as your main application, and your servers are under load (which is often what causes the incident), your status page may also be slow or unavailable.

The solution is to host the status page on infrastructure that's independent of your main stack. A CDN-served static page, or a page on a completely separate hosting provider, ensures that users can always reach it.

No mobile optimization

When something is broken, users often check the status page on their phone — walking around, away from their desk, in the middle of something else. A status page with tiny text, horizontal scrolling tables, and buttons that are hard to tap is a failure of basic product thinking.

PingBase status pages are fully responsive — readable on a 375px screen with no horizontal scroll.

---

The custom domain question

Your status page should live on your domain: status.yourcompany.com, not yourcompany.somethirdparty.io.

The reasons are practical and trust-related:

• Findability: status.yourcompany.com is guessable. Users type it directly. A third-party subdomain is not discoverable.
• Professionalism: A custom domain signals that you've invested in your reliability infrastructure. A generic third-party URL signals the opposite.
• B2B sales: Enterprise customers and procurement teams check for a status page during vendor evaluation. A custom domain on your own brand looks like a real company.

PingBase supports custom domains on Pro ($9/month). Setup is one CNAME record — takes about 2 minutes. SSL is handled automatically.

---

Design checklist

When evaluating your status page, run through this list:

• Current aggregate status is visible without scrolling
• Service is broken into meaningful components (not just one monitor)
• 90-day uptime history is visible per component
• Page loads in under 2 seconds, even when your main site is slow
• Page is usable on mobile at 375px width
• Incident timeline is visible during active incidents
• No ads on any plan
• Custom domain on your own brand
• Status page URL is in your app, docs, and onboarding emails
• Incidents are closed with a resolution message, not just "resolved"

If you're checking your current status page against this list and finding gaps, most of them are fixable in under an hour. The custom domain and component breakdown are the two highest-impact changes — do those first.

---

What PingBase status pages include

PingBase status pages are built around this design checklist:

• Real-time status with automatic updates — no manual refresh needed
• Per-component 90-day uptime history bars
• Incident timeline with status states (Investigating, Identified, Monitoring, Resolved)
• Served from Cloudflare's edge — loads fast even during your worst incidents
• Fully mobile-responsive
• No ads on any plan
• Custom domain support on Pro (one CNAME, SSL auto-provisioned)
• Embeddable uptime badges for README files and docs

The free tier includes a full status page at pingba.se/status/your-slug. Upgrade to Pro for a custom domain.

See the live demo status page to see what it looks like in practice.