A Status Page is a dedicated website, hosted outside of your main infrastructure, that communicates the current health of your services to the outside world. It is the digital billboard for your incident — the one place every stakeholder, customer, and support agent should be directed to for authoritative information.
Why the Status Page Must Be Independent
If your main website is down, your status page must still be up. This sounds obvious, but it's a common failure: companies host their status page on the same infrastructure as the product it monitors. When the product goes down, so does the status page — exactly when customers need it most.
The status page must be hosted on completely independent infrastructure, ideally with a separate DNS provider, CDN, and hosting platform. Managed services like Atlassian Statuspage, PagerDuty Status, Cachet (self-hosted), or Instatus are purpose-built for this. They handle the hosting independence for you and provide APIs to automate status updates from your monitoring systems.
Public vs. Private Status Pages
The same incident looks different depending on who is reading about it. A customer needs to know if they can do their job. An engineer needs to know which service is failing and why. An executive needs to know the business risk. These audiences require different messages — which is why most mature organizations maintain two separate status pages.
1. Public Status Page (For Customers)
- Audience: End-users, customers, the general public, third-party integrators.
- Content: High-level impact framed around the user experience. Focus on what the user cannot do, not what is technically broken.
- Tone: Calm, professional, empathetic, and non-technical. Avoid all internal jargon.
- Update cadence: Every 20–30 minutes during an active incident, even if there is nothing new to report.
- Example: "We are currently experiencing an issue affecting checkout. Customers may be unable to complete purchases. Our team is actively investigating. Next update in 30 minutes."
2. Private Status Page (For Internal Stakeholders)
- Audience: Customer support agents, account managers, executives, partner engineering teams, on-call escalation paths.
- Content: Detailed technical information — root cause hypotheses, specific regions or services affected, error rates, estimated time to recovery (ETR) if known, and links to the internal incident channel.
- Tone: Technical, precise, and transparent about severity and uncertainty.
- Example: "SEV1 Incident: Primary payment gateway API is returning 503 errors in the
eu-central-1region. P99 latency has spiked to 5s. Error rate at 87%. Network team is investigating a potential upstream provider issue. ETR unknown. Incident channel: #inc-2024-0712-payments."
The private page gives support agents the context they need to handle inbound customer calls intelligently, without requiring them to interrupt the engineering team.