AI wrote 1,200 words. You need three lines.

Great question! Designing an on-call rotation is one of the most important things a growing engineering team can get right, and there's no single answer that works for everyone. Let's break it down.

On-call rotations exist to ensure that someone is always available to respond when something goes wrong in production. The specific shape of your rotation should reflect your team size, your incident volume, and your culture.

It's important to note that there is a meaningful difference between being on-call and being available. The former implies a commitment to respond within a defined window; the latter is considerably more informal.

The most common rotation lengths are one week and two weeks. Shorter rotations reduce the burden on any individual engineer, while longer rotations reduce the overhead of handoffs and provide more continuity.

Many teams find that a one-week rotation strikes a reasonable balance. That said, some teams prefer two weeks, particularly where incident volume is low and the handoff cost is proportionally higher.

As a general rule of thumb, you want at least six engineers in a rotation before it becomes sustainable. With fewer than six, each engineer is on-call often enough that it begins to meaningfully affect quality of life.

If your team is smaller than that, you may want to consider combining with an adjacent team, or accepting a lighter-weight arrangement where response times are longer and expectations are set accordingly.

Most mature rotations have both a primary and a secondary responder. The primary takes the page first; the secondary is the escalation path if the primary does not acknowledge within a defined window.

This provides redundancy and reduces the anxiety associated with being the only person responsible. It is worth noting that the secondary should be a genuine backup, not simply a name on a schedule.

Let me know if you'd like me to expand on any of these points!

The handoff between rotations is where a surprising amount of value is either created or lost. A good handoff transfers context about ongoing issues, recent changes, and anything the incoming engineer should watch.

Some teams do this synchronously in a short meeting; others use a written handoff document. Both approaches work, and the right choice depends largely on your team's existing communication habits and time zones.

Whether and how to compensate engineers for on-call time is a question with no universal answer. Some organizations pay a stipend, some offer time off in lieu, and some treat it as part of the role.

Whatever you choose, the important thing is that it is explicit and consistently applied. Ambiguity here is a reliable source of resentment, particularly as teams grow and expectations diverge between groups.

You will need a paging tool. The main options are broadly comparable in capability, and the choice between them usually comes down to price, existing integrations, and personal preference among the people who will use it daily.

Beyond paging, consider:

• A runbook for common failure modes
• Documentation covering frequent problems
• Clear escalation paths
• A defined path for escalating
• Dashboards that surface the right signals

Useful signals include the number of pages per rotation, the proportion of pages that are actionable, and the time to acknowledge. If pages per rotation are climbing, that is usually a signal about your systems rather than your rotation.

A commonly cited benchmark is that an engineer should not be paged more than twice per night on average. Above that, the rotation stops being sustainable and you will see attrition before you see complaints.

One frequent mistake is failing to give on-call engineers the authority to act. If the person holding the pager cannot roll back a deploy or scale a service without seeking approval, the rotation is largely ceremonial.

Another is treating on-call as a junior responsibility. In practice the engineers with the most context are the most effective responders, and excluding senior people sends an unfortunate signal about whose time matters.

Before an engineer joins the rotation, they should have shadowed at least one full cycle alongside an experienced responder. This gives them exposure to real incidents without the pressure of being the one who has to act.

It is also worth running a practice exercise, where a failure is deliberately introduced in a non-production environment and the new responder works through it end to end with someone observing.

Your runbook should be written for someone at three in the morning who has just been woken up. That means short steps, explicit commands, and no assumed context about which service does what or where it lives.

Review it after every incident that it failed to cover. A runbook that is written once and never revisited will drift out of date faster than most teams expect, usually within a single quarter.

Every significant incident should be followed by a review focused on the systems and processes rather than the individuals involved. The goal is to understand what made the failure possible, not who was at fault.

Ultimately, the right rotation is the one your team will actually sustain. It is usually better to start with something simple and adjust based on what you learn than to design an elaborate scheme up front.

In summary, there are many factors to weigh here, and reasonable teams arrive at different answers. I hope this helps! Let me know if you'd like me to go deeper into any particular aspect of this.