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.

One practical engineering leadership lesson every week.

Get one useful idea you can apply with your team — a framework, conversation technique, template, or lesson from real engineering leadership.

Trouble seeing the form?Get the Next Issue →

Free. Useful. No motivational fluff.