How do you make an on-call rotation sustainable?

Direct answer

What a strong answer covers

How it works

A sustainable rotation is designed around the humans in it. Pages must be actionable and symptom-based, so a page means users are affected and there is something to do. Frequency is bounded, with a target such as no more than two pages per shift, and exceeding it is treated as an engineering problem. Every alert links to a playbook, responders have safe access and automation for the common mitigations, and escalation paths are clear. Time after a night page is protected, new members shadow before they are primary, and a share of engineering capacity is reserved to remove the recurring causes of pages.

Example

A team tracked pages per week and found 60 percent came from one flaky disk-space alert and a batch job that failed on weekends. They replaced the disk alert with a burn-rate alert on the SLO, made the batch job retry automatically, and reserved 20 percent of the next two sprints for reliability work. Pages dropped from 14 a week to 3, and the rotation went from one week in four to one in six as two engineers rejoined it.

Common mistakes

• Paging on CPU or disk thresholds that need no human action.
• Running a rotation with three people and calling burnout an individual problem.
• Having no budget to fix the causes, so the same page fires every week.

A useful answer structure

Answer from your own work.

Do not memorise a script: use only examples you can explain honestly in follow-up questions.