Status Pages for SaaS
A straightforward status-page workflow for SaaS teams.
Status pages for SaaS: expose dashboard, API, authentication, and billing as customer components — each backed by a check — and keep internal queues and databases private.
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.
Mapping SaaS internals to public components
The skill in a SaaS status page is translation: turning an architecture of services, queues, and databases into a short list of components a customer understands. Group by what the customer does, not by how you built it. "Sign in" is a component even though it spans an auth service, a session store, and a database — customers experience it as one thing. "Background processing" belongs on the page when delayed jobs (exports, notifications, syncs) are something customers feel, expressed as impact rather than as "worker-pool-2." Keep the raw internal pieces — the database, the message queue, the cache — off the public page, and monitor them privately with alerts to your team. The public page answers "does my workflow work?"; your internal monitoring answers "why not?"
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.