Status Page Guide

What this guide covers

This guide focuses on turning raw monitor state into a page customers can understand before they open a support ticket. The goal is to make the operating decision clear before a stressful incident forces the team to improvise.

• Translate internal systems into the services customers recognize.
• A public page deflects support tickets during an incident.
• Fewer, clearer components beat an exhaustive dependency list.

How Sandglass supports the practice

Attach only customer-facing checks to the public page, name components in customer language, and keep internal-only services out of the public view. Sandglass supports the continuous side of this work with checks, incidents, alert routing, and public status visibility.

• Back the practices here with HTTP, ping, TCP, content, SSL certificate, and heartbeat checks.
• Route incidents to email, Slack webhook channels, and generic webhooks so the right people respond fast.
• Use a public status page to keep customers informed while the team works the incident.

Common mistakes to avoid

A status page becomes noise when it mirrors every internal dependency. Customers need the services they use, the current state, and a clear place to check during incidents.