--- 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 --- [All posts](/blog) [Reliability](/blog/category/reliability) May 27, 2026 · 4 min read · WatchFor Team # On-Call Best Practices: a rotation that doesn't burn people out 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). [#on-call](/blog/tag/on-call)[#incidents](/blog/tag/incidents)[#sre](/blog/tag/sre)[#culture](/blog/tag/culture) ## Run on-call in WatchFor Rotation schedules, one-click overrides, escalation chains that stop on acknowledge and compensation-ready shift totals — built into your monitoring. [Learn more](/on-call)[Start free](/auth/sign-up) Share this article --- Canonical page: https://watchfor.io/blog/on-call-best-practices · Site guide: https://watchfor.io/llms.txt