Status page

A status page communicates whether your service is operational, surfaces component-level status and historical uptime, and hosts incident updates so customers can self-serve answers instead of flooding support. It is the public face of your reliability — the first place users look when something feels wrong.

Why it matters: during an incident, a clear status page is the difference between a calm, informed customer base and a wave of duplicate tickets and angry messages. Proactive, honest updates build trust over time; a service that owns its incidents publicly often earns more goodwill than one that hides them. Subscribers can also opt into notifications so they hear about issues without checking the page.

A common misconception is that a status page can simply live inside your main application. The whole point is that it must stay available when your service does not, so it should be hosted independently of the infrastructure it reports on. A status page that goes down with the outage it is meant to describe is worse than none at all — the best ones render from a last-good snapshot even when the underlying API is degraded.

Effective status pages combine real-time component status, a clear incident timeline (investigating, identified, monitoring, resolved), historical uptime, and a subscription option. Many teams also run private or audience-scoped pages for internal or enterprise-only visibility.