On call without burning out

If you work in DevOps or SRE, you probably know the feeling: the phone on the bedside table, volume up. Checking it before falling asleep. Not going too far from the laptop on a Sunday. Jumping at every buzz, even when it's just a message from a friend.

On call is part of running production systems. Someone has to respond when things break. But it doesn't have to wear people down. Done well, on call is manageable, even educational. Done badly, it's one of the fastest ways to burn out a team.

What makes on call hard

It's rarely the big incident that breaks people. It's the accumulation:

• Too many pages, most of them not needing action.
• Night pages, again and again, ruining sleep for days after.
• Too few people in the rotation, so it comes around too often.
• Not knowing what to do: unfamiliar systems, missing runbooks, no one to escalate to.
• Constant low-level anxiety, even when nothing happens.
• No recognition or compensation for the time and stress.

A fair rotation

Some principles for a healthy rotation:

• Enough people. As a rough guide, at least six to eight people per rotation, so each person is on call around one week in six or eight. With fewer than four or five, it gets very hard to sustain.
• Primary and secondary. A second person as backup means nobody feels completely alone, and there's a fallback if the primary can't respond.
• Reasonable shift lengths. One week is common. Some teams split weekdays and weekends.
• Follow the sun if you have teams in different time zones: each region covers its own daytime, so nobody gets paged at night.
• Easy swaps. Life happens. Make trading shifts simple and normal.
• Proper handovers: what happened during the last shift, what's still open, what to watch.
• Onboarding: new people shadow an experienced engineer before going on call alone.

A healthy on-call rotation is measured by how well people sleep, not just by how fast they respond.

Fewer pages

The most effective way to improve on call is to reduce how often it's needed.

• Every page must need urgent human action. If it doesn't, downgrade it to a ticket or remove it.
• Alert on symptoms users feel, ideally SLO burn rates, not on every CPU spike.
• Track pages per shift and review them weekly or monthly as a team.
• Fix recurring causes. If the same alert fires every week, the fix belongs in the backlog with real priority.
• Automate the known fixes. If the response to an alert is always "restart the service", automate it, and then fix why it needs restarting.
• Protect deployments: avoid risky changes on Friday evenings and before holidays, and use progressive delivery so problems are caught early.

Google's SRE guidance suggests aiming for a small number of incidents per shift, so engineers have time to handle each properly and follow up. If your team regularly gets many pages per night, that's a reliability problem, not a people problem.

Being paid for it

On call is work. It limits your freedom, even when nothing happens. Fair compensation matters:

• A standby allowance for being on call.
• Extra pay or time off for actual incidents, especially at night and on weekends.
• Time off after a bad night. If you were up at 3 a.m. fixing production, you shouldn't be expected at the 9 a.m. stand-up.

In Germany and much of Europe, working time and rest period rules also apply to on call. Rest periods after night work aren't just nice, they can be a legal requirement. Check with HR how your company handles it.

Support during incidents

• Clear escalation paths. Who to call when you're stuck, at any hour.
• Runbooks for every alert.
• No blame. People need to feel safe asking for help or admitting they don't know.
• Incident commander role for bigger incidents, so the person on call doesn't have to coordinate and fix at the same time.

Looking after yourself

Some personal habits that help me and colleagues:

• Prepare at the start of your shift: laptop charged, VPN and access working, recent changes reviewed.
• Set boundaries: on call means available, not glued to the screen. Live your life, just within reach.
• Use a separate notification profile so only real pages break through at night.
• Hand over properly at the end of your shift, and then actually switch off.
• Talk about it. If on call is affecting your sleep, health or relationships, tell your manager. It's a signal the system needs fixing.

For managers

• Look at the numbers: pages per shift, night pages, time to recover, and how people feel.
• Treat on-call load as a reliability metric, and make reducing it a priority.
• Make sure the people who build the systems share the on-call duty. It's the strongest incentive to build reliable software.
• Join the rotation yourself, or at least the escalation path.

So, what's a good first step?

Look at last month's pages together as a team. Count how many needed action, and how many happened at night. Pick the three noisiest alerts and fix or remove them. That single meeting often makes the next month noticeably calmer.

My take: production systems need to be reliable, and so do the people who look after them. Protect both.

— Desly