Uptime Monitoring Guide
A practical reliability guide for teams setting uptime goals.
Uptime Monitoring Guide from Sandglass: practical guidance for choosing the smallest set of checks that proves a service is available from the outside.
What this guide covers
This guide focuses on choosing the smallest set of checks that proves a service is available from the outside. The goal is to make the operating decision clear before a stressful incident forces the team to improvise.
- Monitor from the outside, the way a real user reaches the service.
- Each check should answer a distinct question, not duplicate another.
- Coverage is about the right checks, not the most checks.
How Sandglass supports the practice
Start with HTTP status checks for web surfaces, add SSL certificate checks for HTTPS risk, and use ping or TCP checks only where they answer a different operational question. 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
More checks do not automatically mean better monitoring. Duplicate checks create alert noise and make ownership harder during real incidents.
Implementation checklist
Step 1: Start from customer impact
Decide which failures in this topic actually reach customers before adding any monitoring.
Step 2: Choose one signal per risk
Match each risk to a single HTTP, content, TCP, SSL certificate, or heartbeat check instead of stacking duplicates.
Step 3: Assign an owner and a channel
Give each alert one owner and one destination — email, a Slack webhook, or a generic webhook.
Step 4: Review after real incidents
Revisit intervals, thresholds, and ownership once a real incident shows what was missing.