Status pages are your communication channel during incidents. But communicating with customers and communicating with engineers require completely different approaches. Customers need: "Checkout is down, we're working on it, ETA 15 minutes." Engineers need: "payment-service OOMKilled, pod restarting, DB connections at 98%."
This is why most organizations need two types of status pages—public and internal. Below, we break down what to show on each, when you need both, and how to set them up.
Public Status Page
Audience
Customers, partners, potential buyers, and media. People who neither know nor should know your architecture. They care about one thing: is the service working? If not, when will it be fixed?
What to Show
User-facing components: "API", "Dashboard", "Payments", "Email Notifications"—not "user-service", "payment-service-v2", "kafka-cluster".
Status levels: Operational / Degraded Performance / Partial Outage / Major Outage. Four levels are sufficient.
Incidents: Timeline with updates every 15-30 minutes. What's affected, the impact, what we're doing, ETA.
History: 90-day uptime history. Demonstrates reliability to prospects and partners.
Subscriptions: Email/webhook notifications for changes. Customers get updates without refreshing the page.
What NOT to Show
Internal service names—they expose your architecture.
IP addresses, hostnames, database names—security risk.
Detailed error messages—"OOMKilled" tells the customer nothing, but tells attackers everything.
Internal metrics—CPU usage, memory, queue depths—those belong on the internal page.
Why It Matters
Reduces support burden: instead of 50 tickets asking "is the site down?"—customers check the status page.
Builds trust: transparency during a crisis increases loyalty after. Companies with status pages are perceived as more mature.
SLA compliance: uptime history on your status page provides evidence for SLA reports.
Internal Status Page
Audience
Engineers, on-call responders, support, and product managers. People who understand your architecture and make decisions during incidents.
What to Show
Per-service health: status of each microservice, database, cache, queue. Include latency and error rates.
Infrastructure: pod/container status, deployment version, resource utilization.
Dependencies: third-party API status (Stripe, AWS, SendGrid). Their outages can be the root cause of yours.
Active deployments: who's deploying right now. Recent deploys are a common incident trigger.
Runbook links: direct links to runbooks for each service.
Why It Matters
Speeds up triage: your on-call engineer opens the internal page and in 30 seconds sees which service is red, which dependencies are affected, what was just deployed. Without it: 10 minutes opening 5 dashboards.
Single pane of glass: support sees the same status as engineers. No need to ask "what's happening with the API right now?"—everything is on one page.
Post-incident context: during post-mortems, the internal page shows the timeline: what failed first, what cascaded.
Comparison
| Criteria | Public | Internal |
|---|---|---|
| Audience | Customers, partners | Engineers, support |
| Components | By capability (API, Payments) | By service (user-svc, payment-svc) |
| Detail level | High-level status | Latency, error rates, resources |
| Access | Public URL | SSO / VPN |
| Incident updates | Customer-friendly | Technical details |
| Subscribers | Email, webhook | Slack, PagerDuty |
| Purpose | Trust and transparency | Diagnosis speed |
Who Needs What
Public Only
Startups, small SaaS teams (1-5 people), and open-source projects. Everyone knows the architecture already; an internal page would just duplicate Grafana dashboards. A public page is for customers.
Public + Internal
Growing teams (5-50 people), B2B SaaS with SLAs, and companies with on-call rotations. Support needs the internal view to answer customer questions. Engineers need quick triage capability.
Audience-Specific Pages
Enterprise: separate status pages for major customers (showing only their services). Partner-specific pages for integration partners. AtomPing supports multiple status pages on a single account.
Setup in AtomPing
Public page: create a status page with user-facing capability-based components. Attach monitors to components. Enable subscriber notifications. Add a custom domain (Pro plan): status.yourcompany.com.
Internal page: create a second status page with per-service components. Restrict access (internal link, don't publish). Attach technical monitors (health check endpoints).
Automation: monitors are tied to components. Check fails → component status changes → incident created → status page updated → subscribers notified. Zero manual actions needed for detection.
Related Resources
Complete Guide to Status Pages — from first component to incident communication
Incident Management Guide — how status pages fit into incident workflows
Incident Communication Templates — what to write on your status page during outages
Status Page Best Practices — components, design, update cadence
FAQ
What is a public status page?
A public status page is a web page accessible to anyone (customers, partners, media) showing real-time status of your services. It displays component health, active incidents, historical uptime, and scheduled maintenance. Examples: status.github.com, status.stripe.com.
What is an internal status page?
An internal status page is only accessible to your team (behind SSO or VPN). It shows more detailed information: individual microservice health, infrastructure metrics, deployment status, and internal dependencies. Used by engineering and support teams for faster incident triage.
Do I need both public and internal status pages?
Most teams benefit from both. The public page communicates with customers (what's affected, when will it be fixed). The internal page helps your team diagnose issues (which service failed, what's the root cause). Without a public page, support gets flooded. Without an internal page, engineers waste time gathering context.
What should I show on a public status page?
User-facing components grouped by capability (API, Dashboard, Payments, Notifications), current status per component, active incidents with updates, uptime history (90 days), and scheduled maintenance. Never expose internal service names, server IPs, or detailed error messages.
Can I use one status page for both public and internal?
Not recommended. Public pages need simplicity and customer-friendly language. Internal pages need technical detail and infrastructure visibility. Mixing them either overwhelms customers with jargon or deprives engineers of useful data. AtomPing supports multiple status pages per account.
How do I handle security concerns with status pages?
Public pages should never reveal architecture details, server names, IP addresses, or vulnerability information. Use customer-facing component names (Payments, not payment-service-v2). For internal pages, use SSO/VPN access control. During security incidents, communicate impact without disclosing attack vectors.