On-Call Without Burning People Out

Every engineer who has been on a bad rotation can describe the feeling. It is not the 3 a.m. page itself. It is the low hum of dread in the days around it: the dinner you half-attend because your phone might go off, the weekend you don't really leave the house, the morning after a night of pages when you are expected to show up and do good work anyway. The page is one bad hour. The dread is a whole week, and it repeats.

Leaders tend to treat that dread as the natural cost of running systems people depend on. It isn't. On-call burnout is almost always a design failure, and like most design failures it is invisible until your best engineers start leaving and citing something vaguer in the exit interview. The good news is that a humane rotation and a reliable system are the same project, not competing ones.

Here is how I think about building one that people can carry for years.

The page is not the cost. The dread is.

If you only measure incidents, you will miss where the damage actually happens. A rotation can have very few real pages and still grind people down, because what exhausts people is not the work of responding, it is the loss of control over their own time. You cannot make plans. You cannot fully switch off. Your brain stays half-allocated to a system that probably will not page you but might.

So the first move is to stop optimizing for fewer incidents and start optimizing for restored control. Most of what follows is about giving engineers their attention back when they are not actively fighting a fire.

People don't burn out from the pages they get. They burn out from the pages they're braced for.

Page a human only when a human must act now

The single biggest source of on-call misery is alerts that should never have woken anyone. If a page fires and the correct response is to acknowledge it and go back to sleep, that alert is not monitoring your system. It is training your engineers to distrust their pager, and a pager people have learned to ignore is worse than no pager at all.

The test for every alert is simple and unforgiving: does this require a human to take an action right now, or can it wait for business hours? If it can wait, it is a ticket, not a page. If it is informational, it is a dashboard, not a page. The bar for waking someone is that a person, not an automated retry, has to do something in the next few minutes or users keep hurting.

Most teams can delete a large fraction of their alerts with that one question and lose nothing but noise. Do it ruthlessly, and revisit it every time an incident review surfaces a page that did not need to happen.

The rotation math has to actually work

You cannot humane-culture your way out of a rotation that is too small. If a handful of people cover the pager every other week, no amount of good intentions will save them, because the math itself is the problem. A sustainable rotation needs enough people that any single person's turn comes around with real recovery time in between, and that primary duty is genuinely shared, not quietly absorbed by the two engineers who happen to know the system best.

A few things that make the math humane rather than just survivable:

• Enough people in the rotation. If the only way to staff on-call is to put the same few names on it constantly, you do not have a staffing plan, you have a slow-motion resignation letter.
• Time zones are your friend. If you have engineers in more than one region, let the sun carry the pager. Nobody should be the default owner of every night just because of where the system was born.
• On-call is compensated, in time or money or both. Carrying the pager is real work with real cost to a person's life. Treat it as invisible and you are asking people to subsidize the company's reliability with their evenings.

The morning after is sacred

If someone is up half the night on an incident, the expectation that they log in at nine and ship features is not toughness, it is waste. Tired engineers make the mistakes that cause the next incident, and the message it sends is that the company will spend your health and not notice.

Make it an explicit, boring rule: a rough night buys you the next day, no permission needed, no guilt attached. The first time a manager visibly takes that day themselves after a bad night, the whole team learns it is real. Recovery time is not a perk you grant. It is part of the operating cost of running systems at night, and you either budget for it or you pay for it later in turnover.

On-call load is a metric, and reducing it is the work

The teams that keep on-call humane treat the load itself as a first-class engineering signal, not a fact of life. They know how many pages fire per shift, how many come at night, how often the same root cause recurs, and whether the trend is going the right way. And then they spend real engineering time bringing those numbers down, the same way they would for latency or cost.

This is the part most orgs skip. Reliability work that removes pages is invisible on a feature roadmap, so it never gets prioritized, so the rotation slowly gets worse, so people leave. If you want a sustainable rotation, the recurring page is not background noise to be endured. It is a bug with a person's sleep attached to it, and it gets fixed.

Every recurring page is a bug you've decided to pay for in someone's sleep instead of someone's sprint.

Who carries the pager is a statement of values

The deepest decision you make about on-call is who holds it. When the team that builds a system also runs it, the pain of a bad 3 a.m. is a direct signal to the people who can engineer it away, and they do, because it is their night on the line. When you route all of that pain to a separate group whose job is to absorb it, the bugs become free to the people writing them, and free things multiply.

The same is true of how you handle the bad night after. Blameless incident reviews are not a soft nicety. The first time a retro turns into a hunt for who broke it, people stop telling you what really happened, and you lose the only thing that makes the system safer over time: the truth about how it actually failed.

A humane rotation is a competitive advantage

Here is the part that should make this easy to fund. Experienced engineers compare notes, and they remember which orgs ran on-call like it respected their lives and which ones ran it like their evenings were free inventory. A rotation people can carry for years is not just kinder. It is a retention and recruiting edge, because the engineers you most want to keep are exactly the ones with the standing to refuse a bad one.

You do not get there by promising people the pager will rarely fire. You get there by designing the rotation so that when it does fire it matters, when it is quiet people can actually switch off, and the load itself trends down because the team treats it as work worth doing. Do that, and on-call stops being the thing that drives your best people out, and starts being one more sign that this is a place that knows how to build.