Skip to content
Back to Operations & SRE

On-Call Rotation

Schedule on-call shifts fairly across the team with follow-the-sun, handoffs, and compensation policies.

Why

On-call is a tax on the engineer paying it — they sleep lighter, can't drink, and context-switch hard when a page fires. A rotation that dumps this tax on one person or one time zone breeds burnout and turnover, and the institutional knowledge of "how we handle this alert" concentrates in one head instead of spreading across the team. A fair rotation (4-6 engineers, 1-week shifts, follow-the-sun where possible) keeps any one engineer on-call <25% of the time, gives everyone the operational muscle memory that makes the team resilient, and surfaces documentation gaps when the on-call isn't the person who wrote the system. Teams that skip rotation end up with a single "ops person" who becomes a bus factor of one.

When

When a service reaches production and needs 24/7 coverage. Re-balance when team size changes by >2 people.

How

1. Size the rotation to the team
   - 24/7 SEV1 coverage needs ≥4 engineers (1-week shifts = ~25% on-call load each)
   - <4 engineers → don't promise 24/7; set business-hours SLA instead
   - Each engineer should be on-call ≤1 week in 4

2. Choose a schedule shape
   - Single team, one TZ: 1-week primary + 1-week secondary (secondary handles overflow)
   - Multi-TZ: follow-the-sun — each TZ handles its own daylight, no night pages
   - Document the handoff: "primary passes open incidents + known issues to next primary"

3. Compensate and protect on-call engineers
   - Pay on-call stipend or comp time; acknowledge the tax explicitly
   - No major feature deadlines during on-call week; protect their focus
   - Post-shift debrief: did they get paged >5 times? → alert fatigue, fix the alerts

4. Rotate the secondary too
   - Secondary is the escalation target; they must also be fresh
   - Don't pair primary+secondary from the same feature team (single point of knowledge)

5. Make the schedule visible and automated
   - PagerDuty/Opsgenie schedule, exported to a calendar the whole team can see
   - No manual swaps via DM — use the tool's swap feature so the schedule stays source-of-truth

Example

# PagerDuty schedule — 1-week primary rotation, 4 engineers
resource "pagerduty_schedule" "payments_primary" {
  name = "payments-primary"
  time_zone = "America/New_York"
  layer {
    name = "weekly-rotation"
    start = "2026-01-04T00:00:00Z"  # Monday
    rotation_turn_length_seconds = 604800  # 1 week
    users = [  # 4 engineers, rotates weekly
      pagerduty_user.alice.id, pagerduty_user.bob.id,
      pagerduty_user.carol.id, pagerduty_user.dan.id,
    ]
  }
}
# Each engineer: on-call 1 week in 4 = 25% load
# Handoff doc (Monday 9am): primary reviews open incidents, posts in #payments:
#   "Taking over from @alice. Open: INC-123 (DB failover in progress). No known issues."
# Policy: no feature deadlines during on-call week; $X stipend per shift

Common Problems

  • ⚠One "ops person" holds the rotation — they burn out, become a bus factor of one, and the team loses resilience when they leave.
  • ⚠No compensation or comp time for on-call — engineers resent the unpaid tax and quietly stop volunteering, collapsing the rotation.
  • ⚠Primary and secondary from the same feature team — both share the same blind spots and the same deploy schedule, defeating the escalation purpose.
  • ⚠Manual swaps via DM that don't update the paging system — the schedule says Alice is primary but Bob swapped; a SEV1 pages Alice who is on vacation.

Best Practices

  • ✓Require ≥4 engineers for 24/7 coverage so no one is on-call >25% of the time; below that, set business-hours SLA instead of pretending 24/7.
  • ✓Compensate on-call explicitly (stipend or comp time) and protect the on-call week from feature deadlines — the tax is real and burnout is expensive.
  • ✓Rotate primary and secondary independently and never pair them from the same feature team — escalation must reach a different knowledge base.
  • ✓Make the schedule a calendar the whole team sees, and require swaps through the paging tool so the schedule is always the source of truth.