Status Pages for Agencies
A straightforward status-page workflow for client-service agencies.
Status Pages for Agencies for Sandglass users who want practical customer-facing service health.
What this status page should answer
Agencies need status pages that separate clients, environments, and ownership. The goal is to prove proactive monitoring without exposing irrelevant internal tooling.
- A separate page or grouping per client keeps incidents unambiguous.
- Only client-facing components belong on a client-facing page.
- Alerts route to the team that owns that specific account.
Building the page in Sandglass
Use groups in Sandglass to organize client checks, publish only the client-facing components, and route alerts to the team responsible for that account.
- 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
Avoid a single mixed page for every client. It confuses customers and makes incidents harder to explain when only one account or property is affected.
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.