Two Types of Status Pages, Two Different Audiences
When setting up incident communication, you need to decide: public vs private status page? The answer depends on who needs to see your service health and what level of detail they need.
A public status page is visible to anyone on the internet. A private status page requires authentication and is only visible to internal teams, specific customers, or partners.
Most companies eventually need both.
Public Status Pages
A public status page is accessible at a URL like status.yourcompany.com without any login required. Anyone can check your service health.
When to Use a Public Status Page
- B2C products where any user might check during an outage
- Developer platforms and APIs where downtime affects your customers' products
- SaaS products that serve as critical infrastructure for other businesses
- E-commerce sites where customers need to know if checkout is available
What to Show
Keep public status pages high-level. Show component statuses (operational, degraded, down) and incident updates with customer-friendly language.
Good public components:
- Website
- API
- Mobile App
- Authentication
- Payments
Don't show publicly:
- Internal infrastructure details (database cluster names, queue sizes)
- Specific server names or IP addresses
- Detailed error codes or stack traces
- Internal team communications
Benefits
Reduced support volume. Customers check the status page instead of filing tickets. Companies report 40-60% fewer inbound contacts during incidents when a status page is available.
Trust and transparency. A public commitment to visibility signals confidence in your product. Enterprise buyers specifically look for status pages during vendor evaluation.
SEO value. Status pages rank for "[your product] status" and "[your product] down" queries, directing frustrated users to accurate information instead of speculation on Twitter.
Private Status Pages
A private status page requires authentication. Only invited team members, specific customers, or partner organizations can view it.
When to Use a Private Status Page
- Internal operations (engineering, DevOps, NOC dashboards)
- Enterprise customers who need deeper visibility as part of their contract
- Regulated industries where infrastructure details can't be public
- Multi-tenant platforms where each customer should only see their own service health
What to Show
Private pages can include more technical detail because the audience is known and often technical.
Additional detail for private pages:
- Infrastructure-level component status (database, cache, message queue)
- Response time metrics and graphs
- Error rate percentages
- Deployment status and recent changes
- Individual tenant/customer health
Benefits
Operational visibility. Internal teams get a single dashboard showing real-time service health without needing access to monitoring tools.
Customer-specific communication. Enterprise customers get updates relevant to their environment, not generic announcements about issues that don't affect them.
Compliance. In healthcare, finance, and government, exposing infrastructure details publicly may violate compliance requirements. Private pages keep this information controlled.
The Hybrid Approach
Most mature organizations use both. Here's how to structure it.
Tier 1: Public Status Page
Visible to everyone. Shows 5-8 high-level components. Updated during customer-facing incidents. Available at status.yourcompany.com.
Tier 2: Customer Portal Status
Visible to authenticated customers. Shows their specific services, SLA metrics, and incident history. Includes more technical detail than the public page.
Tier 3: Internal Operations Dashboard
Visible to engineering and ops teams only. Shows infrastructure-level components, real-time metrics, deployment status, and detailed alerting information.
Each tier adds more detail and restricts access further. An incident might show as "API: Degraded Performance" on the public page, "API: Elevated latency on US-East endpoints (p99 > 2s)" on the customer portal, and "API: PostgreSQL primary in US-East-1 at 95% CPU, connection pool at 82%" on the internal dashboard.
Security Considerations
Public Pages
Don't reveal information that helps attackers. Avoid showing:
- Specific infrastructure providers or regions (e.g., "AWS us-east-1 database")
- Version numbers of software components
- Internal hostnames or IP addresses
- Detailed error messages that expose code paths
Keep component names generic: "Database" not "PostgreSQL 15.2 on RDS."
Private Pages
Use proper access control:
- SSO integration for internal pages (don't create separate credentials)
- IP allowlisting for sensitive dashboards
- Audit logging for who views what
- Automatic access revocation when employees leave or customers churn
Status Page Availability
Your status page must be hosted on separate infrastructure from your main product. If your AWS region goes down and your status page is in the same region, customers get silence when they need information most.
Use a status page provider that hosts on independent infrastructure, or self-host on a different cloud provider than your primary service.
Making the Decision
| Factor | Public | Private | Both |
|---|---|---|---|
| B2C with general users | Best | No | No |
| B2B SaaS with technical users | Good | Good | Best |
| Enterprise with SLA contracts | Not enough | Good | Best |
| Regulated industry | Risky | Best | Depends |
| Internal tools only | No | Best | No |
| Developer API platform | Best | Also good | Best |
If you're a SaaS company with both self-serve and enterprise customers, start with a public page and add a private tier when enterprise customers request it. Tools like alert24.net, Statuspage, and StatusPal support both public and private pages within a single account.
Most teams start public. Add private layers as your customer contracts and compliance requirements demand it.