Some teams keep status behind a login because the uptime history looks embarrassing. That is understandable and usually wrong for a product people pay for.
Public
Anyone with the link can see components, history, and incidents. Prospects can check you before a sales call. Customers can self-serve during an outage instead of opening ten tickets.
Use public when:
- External users depend on the product
- You sell reliability as part of the deal
- Support wants a URL to paste
See also do you need a status page.
Private
Password-protected pages, or allowlisted viewers via your own proxy. Tallwatch private pages use a password today (SSO-gated status pages are not shipped). Useful for:
- Internal platform teams
- Pre-launch products with friendly betas who already have Slack
- Components that reveal sensitive architecture you are not ready to show
Private is not a substitute for honesty with paying customers. If only you can see the red banner, they will invent a worse story on Twitter.
Hybrid patterns
- Public page for customer-facing components; internal dashboard for deeper ops.
- Public page with less granular components (App, API, Billing) so you do not expose every internal name.
Granularity is a better privacy control than locking the whole page.
Switching later
Starting private is fine. Put "go public" on the checklist for first paid customer or first SLA. Migrating DNS to status.yourdomain.com is the same either way.
Default bias for customer-facing SaaS: public, hosted separately, updated from real monitors. Privacy by vagueness of components, not by hiding the weather.
