Back to Frameworks
TPL-20Reliability

On-Call Rotation Design

On-call is a leadership decision, not a scheduling decision. Get it wrong and you'll burn out the engineers you can least afford to lose.

Scope of the rotation

  • Which services, alerts, and business hours are covered
  • Primary vs. secondary responsibilities
  • Explicit escalation paths — including 'wake the manager'

Load and compensation

Target pages per rotation. If it's exceeding that, fix the alerts before you fix the schedule. Compensation model — comp days, on-call pay, or both — written down.

Handoff ritual

Every rotation ends with a written handoff: open incidents, alerts to watch, changes to context. 10 minutes of writing saves a night of confusion.

Feedback loop

Monthly review of every page: was it actionable? Was it in-hours or off-hours? Kill alerts that don't earn their weight.

Common pitfalls

  • Primary-only rotations. One person going on holiday breaks the whole system.
  • Ignoring off-hours pages in metrics. Off-hours is where burnout lives.
  • Never touching the alert set. Every quiet alert is technical debt.

Leadership in your inbox.

Leadership lessons, frameworks, and field notes for modern engineering teams. No motivational fluff.

Trouble seeing the form?Subscribe on Beehiiv instead

Free. One email a week. Unsubscribe anytime.