## TL;DR
On-call burns people out when everything pages, rotations drag on, and rest is theoretical. Fix it with a tight page definition, one-week rotations, real comp time after incidents, and a handoff ritual that actually transfers context. Sustainable on-call is a design problem, not a toughness problem.

## The query

```text
support on-call rotation that doesn't burn people out
```

## Use this when

- Setting up support on-call for the first time
- On-call volunteers are drying up
- People dread their on-call week
- Post-incident exhaustion is hurting day shifts

## Not for

- Engineering on-call design
- Incident response runbooks
- Deciding support headcount
- Day-shift scheduling

## Steps

### 1. Define exactly what pages, in writing

Outages, security signals, and S1 customer impact: that is the page list. Everything else waits for morning. If the definition is vague, everything feels urgent at 2am and the rotation becomes dread.

Expected output: a page list short enough to fit on an index card.

### 2. Keep rotations to one week

One week on, several weeks off. Longer rotations accumulate fatigue faster than people admit; by week three of a rotation, judgment is measurably worse. Short rotations with real breaks beat heroic long ones.

Expected output: nobody is on-call two weeks in a row.

### 3. Compensate with rest, not just money

A rough night earns the next morning off, no questions, no heroics required. Write this into the policy so taking the rest doesnt feel like asking a favor. Money is nice; sleep is the actual compensation.

Expected output: post-incident rest is automatic, not requested.

### 4. Run a real handoff ritual

Outgoing on-call briefs incoming: what is flaky, what is being watched, which customers are mid-incident. Fifteen minutes, written down. Handoffs that are just "good luck" transfer anxiety instead of context.

Expected output: every rotation starts with a written brief from the last one.

### 5. Review the rotation itself quarterly

Page counts per person, false-page rate, rest actually taken. If one person got paged fifteen times and another twice, the rotation is unfair regardless of what the schedule says. Fix the paging before you blame the people.

Expected output: a quarterly fairness check with adjustments.

## Ready-to-use rotation rules

```text
ON-CALL RULES

Pages: outages, security signals, S1 customer impact only.
Rotation: one week, no back-to-back weeks.
Rest: rough night = next morning off, automatic.
Handoff: 15-minute written brief between rotations.
Review: page counts and fairness, quarterly.
```

## Variant phrasings

### how to set up support on-call without burnout

Steps 1 through 3. Tight page definition, short rotations, real rest.

### sustainable on-call schedule for customer support

Steps 2 and 5. Rotation length plus the quarterly fairness review.

### on-call compensation best practices for support teams

Step 3. Rest as compensation, written into policy.

## Why it happens

On-call burnout is rarely about the total hours; it is about unpredictability plus lack of recovery. A 2am page you recover from is fine; a 2am page followed by a full day shift, repeated for three weeks, is what breaks people. The design fixes target the recovery gap, not the page count.

## Edge cases

- Tiny team, unfair frequency: acknowledge it openly, pay the on-call premium, and make reducing page volume the top ops priority.
- Someone never gets paged: check the routing before celebrating. Silent on-call usually means alerts are misconfigured, not that things are quiet.
- The same incident pages repeatedly: that is an engineering problem wearing an on-call costume. Escalate the underlying fix.
- Holidays: plan coverage explicitly, with volunteers and premium comp. Surprise holiday pages are the fastest trust killer.
- On-call during a launch: staff it deliberately with extra hands. Launch weeks are predictable; the burnout from them should be too.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5ReGOy82hLLInFj_y2MGQw