On-Call for Small Teams — You're Not Google, and That's Fine

Most on-call advice is written by and for companies with hundreds of engineers: follow-the-sun rotations, dedicated incident commanders, SRE teams whose whole job is the pager. Then a three-person startup reads it, tries to copy Google, and ends up with an elaborate process nobody follows and a founder who hasn't slept properly in a year.

On-call at 2–5 people is a different job. You can't spread the pain across forty engineers, everyone is close to the code, and the person who gets paged also ships features the next morning. Small teams can still run a humane on-call, but only by being strict about what pages, honest about the rotation, and prepared enough that whoever answers can actually act.

The honest rotation

With 2–5 people, the math is unforgiving: a weekly rotation on a three-person team means carrying the pager one week in three, forever. So design for sustainability, not for org-chart aesthetics:

• One primary at a time, always. The worst small-team pattern is "alerts go to everyone", which reliably becomes everyone assumes someone else is on it. Name a primary. When they ack, everyone else stands down.
• Week-long shifts, handed over deliberately. A weekly cadence beats daily (less context-switching) and monthly (less burnout). Do a two-minute handover: anything flaky right now, anything mid-migration, anything to watch.
• Everyone rotates, including the founder or lead. Nothing improves alert quality faster than the person with the most power to fix things personally eating the 3 a.m. pages. Exempting seniors is how noisy alerts become permanent.
• Two people? Then it's an alternation, not a rotation, and the escalation path is simply each other. That's fine. Write it down anyway.

What deserves a 3 a.m. page (very little)

The most important on-call decision is the paging bar. For a small team, the honest test is: would we want a specific human to get out of bed and fix this before morning? Apply it strictly and the list gets short:

• Yes: production fully down or hard-failing for customers; the payment/checkout path broken; data loss in progress; a security incident underway.
• No: a background job failed once and will retry; disk at 80%; the staging box; a certificate expiring in three weeks; the site being somewhat slow. All of these are morning work: a chat message, an email, a ticket.

Everything on the "no" list still gets monitored and still gets alerted, just into channels that respect sleep. The distinction isn't tracked vs ignored; it's interrupt vs inform. Small teams that page on everything don't get more reliability. They get a worn-out primary who starts sleeping through the pages that matter. We've written about that spiral before: alert fatigue is a design failure, and at small scale the constraint is that human attention is the scarcest resource you have.

Alert quality over coverage

Big companies can absorb noisy alerts because there's always another layer of on-call. You can't. At small scale every false page comes straight out of one specific person's sleep and next-day output, so the trade is different:

• Confirmed, symptom-based pages only. A page should mean "users are affected, and we confirmed it", not "one probe hiccuped" or "a metric crossed a line."
• Prune monthly. Any page that fired without producing action gets demoted or deleted. Eight alerts you trust beat eighty you triage on instinct.
• Count pages per week. More than a handful per shift is a problem in itself: either reliability needs work, or your alerting does.

Runbooks: so the non-expert can respond

On a small team, the person paged is often not the person who knows that system best. The database person is on holiday and the frontend person is holding the pager. Runbooks are how that works anyway.

Keep them practical: one page per failure mode, written for someone stressed and half-awake.

RUNBOOK: API down / 5xx spike
1. Check host status page — provider outage? If yes: status page update, monitor, go back to bed.
2. SSH: ssh deploy@api-1
3. Check the service:    systemctl status app
4. Restart if dead:      systemctl restart app   (safe — takes ~20s)
5. Still failing? Check disk (df -h) and logs: tail -100 /var/log/app/error.log
6. Beyond this → escalate to Priya (see escalation), even at night. That's the agreement.

What makes them work: exact commands, explicit "this is safe to try" markers, and a defined give-up point. A runbook that lets the non-expert resolve most pages, and escalate the rest without guilt, is worth more than any dashboard. Write one after every incident while the details are fresh; that's the whole documentation process.

Compensation and expectations: say it out loud

Small teams tend to leave on-call implicit, and implicit means unfair. Norms vary (some pay a flat weekly stipend, some trade pager weeks for time off, some fold it into salary explicitly), but the specific choice matters less than three things being said out loud: on-call is work even when nothing fires, because being available is the cost; a rough night earns a slow morning, with no heroics expected at standup; and the response-time expectation is written down (e.g. "ack within 15 minutes, laptop within 30") so nobody is silently assuming five.

Escalation: when the primary sleeps through it

It happens: phones on silent, dead batteries, deep sleep. Plan for it mechanically, not morally:

1. Page fires → primary. No ack in 10–15 minutes → page again, louder channel.
2. Still nothing → page the secondary (on a 2-person team, the other person; on a 3–5 person team, last week's primary is a natural default).
3. Still nothing → the all-hands channel that everyone has un-muted.

Two rules make this humane. First, escalation is never a failing; the system worked, which is why layers exist. A team that treats being slept-through as shameful ends up with people afraid to sleep. Second, test the chain quarterly with a deliberate drill (a fake page at an unannounced time), because an escalation path that has never fired is a hypothesis, not a safety net.

Small, sustainable, awake when it matters

You're not Google. You don't need an incident commander, a NOC, or a 47-page severity matrix. You need one named primary, a short list of things worth waking for, confirmed alerts routed by severity, runbooks a non-expert can follow, honest compensation, and an escalation chain that has been tested. That fits on one page, and it will still be working in a year.

CompleteStatus handles the plumbing underneath: failures are re-checked before anyone is alerted, alerts are routed by severity so 3 a.m. is reserved for real emergencies, and recovery notices tell the primary when to stand down, across uptime, SSL, DNS and cron-heartbeat checks. Create a free account if you want to try it with your rotation.