On-Call Rotation for a Small Team: A Worked Schedule

Say you have five engineers: Ana, Ben, Chi, Dev and Eli. Each week one is primary (gets paged first) and the previous week's primary is secondary (gets paged if the primary doesn't acknowledge). This means everyone knows the system state from last week when they're backup.

1. Week 1: Ana primary, Eli secondary.
2. Week 2: Ben primary, Ana secondary.
3. Week 3: Chi primary, Ben secondary.
4. Week 4: Dev primary, Chi secondary.
5. Week 5: Eli primary, Dev secondary, then the cycle restarts.

With five people, each engineer is primary one week in five. With only three, that becomes one in three, and burnout follows quickly. If you can't reach four people, reduce what pages (see the alerting section below) before you shorten the rotation.

Handoffs are where context gets lost. Hold a fifteen-minute call or write a note on the same weekday and time each week. It should cover:

• Open incidents and anything flapping that hasn't been fixed.
• Deploys or migrations scheduled during the coming week.
• Alerts that fired often, and whether they were real.
• Vendor maintenance windows and known risky dates, such as a customer launch.
• Anything you'd want to know if you were about to be woken up.

Keep the notes in one running document so the incoming person can scan the last month, not just the last week.

Write the rules down so they aren't renegotiated during a bad week:

• Swaps: anyone can trade a week with a teammate if both agree and the schedule tool or shared calendar is updated the same day.
• Response expectation: define how quickly the primary must acknowledge, in minutes, and what happens if they don't. Escalation to the secondary should be automatic, not manual.
• Recovery time: if someone is paged overnight, they start later or take time off the next day without asking permission.
• Holidays: rotate the holiday weeks deliberately, or offer extra compensation, instead of letting the same person absorb them.
• New joiners: shadow one rotation before going primary, and pair them with a secondary who knows the system.

Compensation is a policy decision that depends on your company and local labor rules, so decide it explicitly instead of leaving it implied. Check with your employment counsel if you have on-call staff in more than one jurisdiction.

A rotation is only sustainable if the alerts are worth waking up for. Review each week's pages and sort them into three groups: needed action now, could have waited until morning, and no action needed. Delete or downgrade the last two groups.

A helpful filter is to page only on symptoms customers feel, such as failing checkouts or elevated error rates, and send cause-level signals like high CPU to a channel instead. If you've defined service level objectives, tie paging to burning through your error budget; the SLO template for small engineering teams shows how. For a look at how delivery health metrics relate, see DORA metrics for a small team.

For two or three people, a shared calendar and a phone-call escalation might be enough. Once you have a real rotation, a paging product earns its place because it handles acknowledgment, escalation and overrides so no one has to remember who's next. PagerDuty and Opsgenie both cover schedules and escalation; the differences that matter for you are how the tool fits into your existing chat and ticketing setup and who administers it. The head-to-head is in PagerDuty vs Opsgenie vs incident.io. Confirm pricing and limits in a demo, since plans change.