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 cosplay 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 sport. You can't rotate away the pain across forty engineers; everyone is close to the code; and the same person who gets paged also ships features the next morning. The good news: small teams can run on-call that's genuinely humane — but only by being ruthless about what pages, honest about the rotation, and prepared enough that whoever answers can actually act. Here's the small-team playbook.

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 actually deserves a 3 a.m. page (very little)

The single 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 become morning work — a chat message, an email, a ticket.

Everything on the "no" list still gets monitored and still gets alerted — 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 fried 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 design constraint is that human attention is the scarcest resource you have.

Alert quality over coverage

Big companies can afford noisy alerts — there's always a fresh layer of on-call to absorb them. You can't. At small scale, every false page is subtracted directly from 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, verified from more than one vantage point" — not "one probe hiccuped" or "a metric crossed a line."
• Prune monthly. Any page that fired without producing action gets demoted or deleted. A small team is better served by eight alerts it trusts absolutely than eighty it triages emotionally.
• Measure pages per week. More than a handful per on-call shift is a fire to fix in itself — either reliability genuinely needs work, or your alerting does.

Runbooks: so the non-expert can respond

On a small team, the person paged is frequently 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 brutally 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.

The magic ingredients: exact commands, explicit "this is safe to try" markers, and a defined give-up point. A runbook that lets the non-expert resolve 70% of 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 love to leave on-call implicit, and implicit means unfair. Norms vary — some pay a flat on-call stipend per week, 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 availability itself is the cost; a rough night earns a slow morning, 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; that's 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, unannounced timing — because an escalation path that's 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 comp, and an escalation chain that's been tested. That fits on one page — and it'll still be working in a year.

CompleteStatus handles the machinery underneath: multi-location confirmation so pages are real, severity-based routing so 3 a.m. is reserved for the genuine emergencies, and recovery notices so the primary knows when to stand down — across uptime, SSL, DNS and cron-heartbeat checks. Create a free account and give your two-person rotation the alert quality a forty-person one would envy.