What Is an On-Call Rotation?

Shift length. Weekly rotations are common, with some teams using shorter shifts to reduce fatigue and others splitting day and night coverage. Follow-the-sun rotations across time zones avoid night work entirely when an organisation is distributed enough to staff them.

Tiers. A primary responder receives pages first. A secondary is paged if the primary does not acknowledge within a set time, which protects against a missed notification. Some teams add an escalation manager for incidents needing coordination or external communication.

Scope. What the rotation covers: specific services, a whole platform, or a shared queue. Ambiguous scope is a common source of unhandled alerts, because everyone assumes someone else owns the page.

Response expectations. Usually an acknowledgement target, such as responding within a set number of minutes, rather than a resolution target. Resolution depends on the problem; acknowledgement is what the rotation can promise.

Handover. A short written handover at shift change covering ongoing incidents, known fragile areas, changes deployed, and anything deliberately deferred.

Tooling. An alerting system that routes pages by schedule, escalates automatically, and records acknowledgements, plus a ticket record so what happened overnight is visible in daylight.

Compensation and working time

Alert quality. The single biggest factor. Pages should indicate that something is broken and requires human action now. Alerts that fire on conditions nobody acts on train responders to ignore the pager, which is how real incidents are missed.

Volume. A rotation that pages several times a night is not a rotation, it is a night shift without the staffing. Track pages per shift and treat sustained increases as an engineering problem.

Actionability. Every alert should link to what it means, what to check first, and what the safe mitigations are. Runbooks written during calm hours save enormous time at 3am.

Authority. Responders need the access and permission to act: restart services, roll back deployments, fail over, and scale. On-call without the ability to change anything is stressful and ineffective.

Fair rotation. Enough people in the rotation that shifts are infrequent, honest handling of swaps and holidays, and no informal expectation that senior engineers are always reachable.

Recovery. Time off after a disturbed night should be normal and expected, not something to be negotiated.

Feedback loop. Incidents feeding fixes, alert tuning, and runbook updates. Without that, the same page recurs indefinitely and morale declines with it.

Solo on-call in small teams

Define ownership first. Which services, which alerts, and who is accountable. Rotations built before ownership is clear inherit every ambiguity.

Start with the pages that matter. Route only alerts that represent user-visible impact or imminent failure to the pager. Everything else goes to a queue reviewed in working hours.

Write the escalation policy. Acknowledgement window, who is paged next, and when an incident commander or manager is involved.

Provide runbooks before going live. Each pageable alert needs a short document: what it means, first checks, safe mitigations, and who to escalate to.

Agree the compensation and recovery rules with the team and with human resources, in writing.

Test the pipeline. Send real test pages through the full chain, including at night, and confirm delivery, escalation, and acknowledgement all work. Alerting systems fail silently.

Review regularly. Pages per shift, how many were actionable, how many were escalated, and how many led to a fix. That review is what stops a rotation degrading into an endurance test.