On-Call When Your Team Is Two People
19 Feb 2026Standard on-call advice assumes a team of six to eight rotating weekly. With two people, that advice breaks: a one-week rotation means every other week is yours, forever, and burnout shows up fast.
Don’t rotate by week
A weekly rotation with two people means 50% of all weeks on call, indefinitely. That’s not sustainable even if the pager rarely fires — the anxiety of being reachable is the cost, not just the interruptions.
Two setups that actually work at this scale:
Business-hours-only paging. If your product can tolerate a few hours of overnight downtime, don’t page overnight at all. Route after-hours alerts to email or a low-urgency channel and check them in the morning. Most small products can survive this. Check your actual uptime commitments before assuming you can’t.
Both on call, alternating first response. Instead of one person owning the whole week, alternate who gets paged first, with both of you loopable for anything serious. This removes the “sole responsibility” feeling without doubling pager noise, since most alerts resolve before a second person needs to wake up.
Set a real threshold for what pages a human
At two people, every unnecessary page is expensive — there’s no slack in the rotation to absorb noise. Define what’s worth losing sleep over before you turn paging on:
| Signal | Page? |
|---|---|
| 5xx rate above 5% for 5 minutes | Yes |
| Single request error | No |
| Disk above 90% | Yes, business hours |
| Disk above 98% | Yes, always |
| Deploy failed | No — check in the morning unless mid-deploy |
| DB connection pool exhausted | Yes |
Write this down. Skip it and you’ll page on everything at first, out of anxiety, then quietly start ignoring pages once you’re exhausted — which is worse than no paging at all.
Give each other a real day off
With two people, “day off” often means “still get paged, resentfully.” Fix it explicitly: pick one day a week where the on-call person hands the pager fully to the other, no exceptions, and both of you honor it. Real incidents still pull in the off-duty person — but routine pages go to whoever’s holding the pager that day, not whoever wrote the code that broke.
Automate the decision, not just the alert
The best thing you can do for a two-person rotation isn’t a better paging tool — it’s fewer decisions at 3am. Auto-restart on health check failure. Auto-scale on queue depth. Auto-rollback on a post-deploy error spike. Every alert that resolves itself before a human looks at it is an alert that didn’t cost either of you sleep.
# auto-restart a crashed container instead of paging for it
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
interval: 10s
retries: 3
restart: unless-stopped
For anything with a clear, safe automatic remediation — restart, scale, rollback — write the automation once and stop paging for that case entirely.
What to skip
Skip the formal escalation policy, the handoff meeting, the pager-fatigue dashboard. At two people you already know when the other person is drowning — you talk to them. Save the process for when you’re six.
The actual goal at this size: make the pager rare enough that being on call doesn’t change how either of you lives that week. If it does, the threshold is wrong, not the rotation.