What is On-Call?

#How on-call is structured

A rotation assigns primary responsibility across a team, most often in weekly shifts. A secondary rotation provides backup when the primary does not acknowledge, and escalation paths reach specialists or management when the situation exceeds what the rotation can handle.

The parameters that determine whether a rotation is sustainable are its size, shift length, alert volume, and the compensation or time off that follows a disrupted night. A rotation of four people receiving frequent overnight pages will not retain those four people.

#Why on-call exists

Systems fail at all hours and users are affected regardless of business hours. On-call converts an unbounded expectation that someone will notice into a defined, compensated responsibility.

• Guaranteed coverage: a specific person is accountable at every moment.
• Bounded expectation: engineers not on-call are genuinely off.
• Feedback loop: teams that operate their own software build it more carefully.
• Response speed: someone is already prepared rather than being found.

#Limits and sustainability problems

On-call is where operational debt is collected. Poor alerting, fragile systems, and missing automation all convert directly into pages, and the rotation absorbs the cost. A team can run indefinitely on a healthy rotation and will lose people to an unhealthy one.

Small teams face the hardest math. A three-person rotation creates a high on-call burden and may be difficult to sustain, especially with frequent pages. Below a certain team size, either the rotation spans teams or the alerting has to be quiet enough that on-call is genuinely uneventful.

#On-call vs an operations team

A dedicated operations team separates the people who build software from the people who run it. It provides deep operational focus, and it also creates a feedback gap: developers do not experience the consequences of what they ship.

Developer on-call closes that gap. The team that writes the service responds to its failures, which aligns incentives toward reliability. The tradeoff is that operational expertise is spread thinner. Many organizations run a hybrid, with a platform team owning shared infrastructure and product teams on-call for their own services.

#Key takeaways

• On-call converts an informal expectation into a defined, compensated responsibility with guaranteed coverage.
• Sustainability depends on rotation size, shift length, alert volume, and recovery time after disrupted nights.
• It is where operational debt is collected, since poor alerting and fragile systems convert directly into pages.
• Developer on-call aligns build and run incentives, at the cost of spreading deep operational expertise thinner.

#Frequently asked

What is a sustainable rotation size?

Six or more people is a common floor for weekly shifts, which puts each engineer on-call roughly six weeks a year. Smaller rotations require correspondingly quieter alerting.

How many pages per shift is acceptable?

Few enough that each one is read carefully and sleep is rarely disrupted. Any recurring overnight page should be treated as a defect to fix rather than a cost to absorb.

Should on-call be compensated?

It is a real constraint on personal time whether or not anything fires. Most organizations compensate with pay, time off after disrupted nights, or both.