On-Call Rotation for a Startup
A practical reliability guide for teams starting on-call.
On-Call Rotation for a Startup from Sandglass: practical guidance for assigning responsibility for production alerts without burning out a tiny engineering team.
What this guide covers
This guide focuses on assigning responsibility for production alerts without burning out a tiny engineering team. The goal is to make the operating decision clear before a stressful incident forces the team to improvise.
- Only true production issues should page overnight.
- Documented known fixes shorten every shift.
- Rotating primary ownership prevents one person burning out.
How Sandglass supports the practice
Group alerts by severity, rotate primary ownership, document known fixes, and keep non-urgent alerts out of overnight paging. 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
The fastest way to ruin on-call is routing every minor staging failure to the same person who handles production outages.
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.