On-Call Rotation for a Startup

What this guide covers

On-call is how a small team makes sure someone responds to production problems outside working hours — without it landing on the same person every night. This guide covers what should and should not page overnight, how to structure a fair rotation on a small team, and how to keep the alert volume low enough that on-call stays sustainable.

• Only true production issues should page overnight.
• Documented known fixes shorten every shift.
• Rotating primary ownership prevents one person burning out.

What should page overnight

The bar for waking someone is high: the issue is affecting customers now and cannot wait until morning. A down checkout flow qualifies; a failed nightly report that can rerun does not. Everything else — degraded-but-working services, staging failures, low-priority background jobs — should route to a channel or email for daytime triage. If you would not personally want to be woken for it, do not route it to the pager.

• Page: customer-facing outages, data loss risk, security events.
• Do not page: staging failures, non-urgent job retries, informational alerts.
• Add a retry threshold so one transient blip never pages anyone.

Structuring a fair rotation on a small team

With only a few engineers, keep it simple: one primary per week (or per few days), rotating through everyone, with an optional secondary as backup for when the primary cannot respond. Publish the schedule so everyone knows when they are up. Compensate on-call time in whatever way fits your culture — time off, pay, or reduced daytime load — because unpaid, unacknowledged on-call is how burnout and resentment start.

Reducing the load, not just distributing it

The best on-call improvement is fewer pages. After each incident, ask whether the alert was actionable and whether the fix can be documented or automated. A runbook entry that turns a 2am investigation into a two-minute known fix pays for itself immediately. Over time, tuning thresholds and eliminating noisy checks matters more than any scheduling tweak.

How Sandglass supports the practice

Separate what pages from what waits by routing alerts by severity in Sandglass: production-down checks go to whatever pages your on-call person, while low-urgency and staging checks go to email or a channel to review during the day. Group checks by environment so the split is clean and nobody is woken by a staging deploy.

• 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. When 90% of overnight pages are noise, people stop trusting the pager and miss the one that mattered. Ruthlessly separate "wake someone up" alerts from "look at this tomorrow" alerts.