Status Page vs Incident Page
A practical reliability guide for teams designing reliability communication.
Status Page vs Incident Page from Sandglass: practical guidance for separating the always-on health page from the timeline for one specific outage.
What this guide covers
This guide focuses on separating the always-on health page from the timeline for one specific outage. The goal is to make the operating decision clear before a stressful incident forces the team to improvise.
- The status page answers "is it working right now".
- The incident page carries the detailed timeline of one outage.
- Mixing the two makes the public page harder to scan.
How Sandglass supports the practice
Use the status page for current component state and the incident page or internal timeline for detailed investigation notes. 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
Combining every note into the public status page can make the page harder to scan when users only need current availability.
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.