Status Pages for SaaS
A straightforward status-page workflow for SaaS teams.
Status Pages for SaaS for Sandglass users who want practical customer-facing service health.
What this status page should answer
SaaS status pages should separate product surfaces like dashboard, API, authentication, billing, and background processing. Each component needs a monitor signal that reflects customer impact.
- Authentication and the dashboard deserve their own components.
- Background processing is a customer-facing component when jobs are delayed.
- Internal queues and databases stay off the public page.
Building the page in Sandglass
Create Sandglass checks for the dashboard and API first, add heartbeat checks for background jobs that affect customers, then attach those checks to the public page.
- Publish a public status page that shows live monitor state for the services customers recognize.
- Back every public component with a real check so the page reflects measured availability.
- Keep internal-only checks private and route their alerts to email, Slack webhooks, or a generic webhook.
What not to publish
Do not publish every database, queue, and worker as a public component. Customers need to know whether their app workflow works, not which internal subsystem is noisy.
Implementation checklist
Step 1: Name components in customer language
List the services customers recognize — website, API, checkout, dashboard — not internal subsystems.
Step 2: Attach a check to each component
Back every public component with an HTTP, content, TCP, or SSL certificate check so its state is measured, not toggled by hand.
Step 3: Decide what stays private
Keep noisy internal dependencies off the public page and route their alerts to your team channel instead.
Step 4: Publish and link it
Add the public status page link to support replies and documentation so customers can self-serve during incidents.