---
title: On-Call Best Practices: a rotation that doesn't burn people out
description: Done badly, on-call wrecks sleep, morale and retention. Done well, it's a fair, calm safety net the whole team trusts. Here's how to build the second kind.
canonical: https://watchfor.io/blog/on-call-best-practices
---

# On-Call Best Practices: a rotation that doesn't burn people out

2026-05-27 · WatchFor Team · Reliability · on-call, incidents, sre, culture

Done badly, on-call wrecks sleep, morale and retention. Done well, it's a fair, calm safety net the whole team trusts. Here's how to build the second kind.

There's an engineer on every team you can spot a mile off: the one who's been on-call too long, on a rotation that pages them three times a night for things that didn't matter. They're exhausted, a little jumpy, and quietly updating their CV.

On-call doesn't have to be like that. Done well, it's a fair, well-understood safety net that the whole team shares and trusts. Done badly, it's a slow-motion way to lose your best people. The difference is almost entirely in the practices — here are the ones that matter.

## What "on-call" really is

On-call is simply **whose job it is to respond when something breaks** at any given moment — including nights and weekends. Someone has to be the person who picks up when the pager goes off. The goal isn't to make that heroic; it's to make it *rare, fair, and humane*.

## The practices that make it humane

### 1. Make ownership crystal clear

At any moment, exactly one person should know "I'm on-call right now." Ambiguity — "I thought *you* had it" — is how incidents get missed. A clear schedule, visible to everyone, removes all doubt.

### 2. Build a real escalation path

The primary on-call shouldn't be a single point of failure. If they don't acknowledge in a few minutes (they're driving, asleep, in a tunnel), it should automatically escalate:

| Tier | Role | Kicks in |
| --- | --- | --- |
| **Primary** | First responder | Immediately |
| **Secondary** | Backup | If primary doesn't ack (~5 min) |
| **Manager** | Last resort | If neither responds (~15 min) |

Nobody should ever be the *only* thing standing between an outage and a fix.

### 3. Keep the rotation fair

Spread the load. A rotation where the same person always covers weekends, or where one team of three is permanently on-call, burns people out fast. Rotate evenly, account for time zones, and make sure everyone gets real time *off* the rotation.

### 4. Only page for things worth waking up for

This is where on-call lives or dies. If the pager goes off for non-actionable noise, people stop trusting it — and miss the real thing. Every page should pass one test:

> **"If this wakes me at 3am, will I be glad it did?"** If not, it shouldn't be a page. Route it to a daytime channel or a dashboard instead.

This is the same discipline that beats [alert fatigue](/blog/alert-fatigue) — and it's the single biggest lever for a humane on-call.

### 5. Give people runbooks

Being paged at 3am is stressful enough without having to reverse-engineer the system from scratch. A short runbook for each common alert — "what this means, how to check, how to fix or who to call" — turns panic into procedure.

### 6. Do humane handoffs

When the shift changes, hand over context: what's flaky, what's in progress, what to watch. A 10-minute handoff saves the next person from walking into a mess blind.

### 7. Stay blameless

When something goes wrong on someone's shift, the response is a [blameless postmortem](/blog/blameless-postmortem), not a telling-off. People who fear blame hide problems — exactly the opposite of what you want from the person holding the pager.

### 8. Compensate and recover

On-call is real work, often at antisocial hours. Recognise it — through pay, time off in lieu, or both — and make sure someone who had a brutal night isn't expected to ship features the next morning.

## Common mistakes

| Mistake | Do instead |
| --- | --- |
| One or two people always on-call | Share the load across a fair rotation |
| No escalation — pages vanish into the void | Auto-escalate to a secondary and manager |
| Paging on everything | Page only on actionable, real impact |
| No runbooks | Write a short one per common alert |
| Treating on-call as invisible/free | Recognise and compensate it |
| Blaming whoever was on shift | Run a blameless postmortem |

## The bottom line

| Principle | In one line |
| --- | --- |
| Clarity | One person always knows they're on-call. |
| Escalation | No one is the single point of failure. |
| Signal | Page only for what's worth waking up for. |
| Humanity | Fair rotation, runbooks, recovery, no blame. |

A good on-call rotation is quiet. The pager rarely goes off, and when it does, it means something — and the person holding it has the backup, the runbook, and the trust to handle it. Build that, and on-call stops being the thing people dread and starts being just another part of running a reliable service.

The fastest way to a calmer rotation is fewer, better alerts — start with [Alert Fatigue](/blog/alert-fatigue) and the [alerting guide](/docs/alerting).

---

Canonical page: https://watchfor.io/blog/on-call-best-practices · All articles: https://watchfor.io/blog/all.md · Site guide: https://watchfor.io/llms.txt