Status Pages for Agencies

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.

One page per client, cleanly separated

For an agency, the status page is both an operational tool and a piece of client-facing proof that you are watching their property. The organizing principle is separation: a group per client keeps each account's checks, incidents, and alerts distinct, so an outage points unambiguously at one client and one owning team. Expose only that client's customer-facing components on their page — never a shared page that leaks one client's status to another, or buries their services among a hundred others. Route each account's alerts to the team responsible for it, so the right people respond first and no one is paged for a client they do not own. The result is faster, clearer incident handling and a standing demonstration of the monitoring you provide.

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.