How to Set Up On-Call Rotations That Don't Burn Out Your Team

On-call doesn't have to be miserable. But at most companies, it is. Developers dread their on-call week, alerts fire constantly for things that don't matter, and the same person ends up fixing everything because the rotation isn't fair. Here's how to build an on-call system that actually works.

The foundation: reduce alert noise first

Before you even set up a rotation, fix your alerting. The number one cause of on-call burnout is alert fatigue — getting paged for things that don't need human intervention.

Audit every alert and ask:

• Does this alert require a human to take action right now?
• Has this alert ever fired and actually indicated a real problem?
• Could this be auto-remediated instead of paging someone?

If an alert doesn't require immediate human action, downgrade it to a Slack notification or a ticket. Only page-worthy alerts should wake someone up. A good target: fewer than 2 pages per on-call shift (typically a week).

Designing the rotation

Team size matters

The minimum viable on-call team is 4 people. With fewer, the rotation is too frequent and people burn out. With a team of 4, each person is on-call one week per month — manageable but tight. Ideally, you want 6-8 people in the rotation.

Primary and secondary

Use a two-tier system:

• Primary — First responder. Gets paged immediately.
• Secondary — Backup. Gets paged if primary doesn't acknowledge within 10 minutes.

This ensures coverage even if the primary is temporarily unavailable (commuting, sleeping through an alert, phone on silent).

Rotation schedule

Weekly rotations work best for most teams. Daily rotations create too many handoffs, and bi-weekly rotations are too long. Hand off at the start of business hours (not midnight) so the outgoing person can brief the incoming person.

// Example rotation schedule
Week 1: Alice (primary), Bob (secondary)
Week 2: Bob (primary), Carol (secondary)
Week 3: Carol (primary), Dave (secondary)
Week 4: Dave (primary), Alice (secondary)

Escalation policies

Define clear escalation paths:

1. 0 min — Alert fires, primary on-call is paged
2. 10 min — No acknowledgment, secondary on-call is paged
3. 20 min — No acknowledgment, engineering manager is paged
4. 30 min — Still unresolved, all-hands page to the team

Make sure the escalation is automated. Don't rely on the primary to manually escalate when they're overwhelmed.

Compensation and fairness

On-call is real work outside normal hours. Compensate it. Common approaches:

• Flat stipend — $200-500/week while on-call, regardless of pages
• Per-incident bonus — Additional compensation for each page responded to
• Time off — A day off after an on-call week with incidents
• Combined — Stipend + time off for heavy weeks

Also track the distribution. If one person is getting more pages than others (because their service area is noisier), fix the imbalance. Either improve that service's reliability or adjust the rotation to share the load.

Tooling checklist

Good on-call requires good tools:

• Monitoring — Uptime checks, health endpoints, error rate tracking
• Alerting — Multi-channel (phone, SMS, Slack, email) with escalation
• Runbooks — Step-by-step guides for common incidents
• Status page — For communicating during incidents
• Post-mortem template — Consistent format for learning from incidents

Making on-call sustainable

The most important thing: treat on-call improvements as engineering work. If an alert is noisy, file a ticket to fix it. If a service keeps breaking, allocate sprint time to improve its reliability. The on-call rotation should get better over time, not worse.

Start with reliable monitoring. If you're looking for a simple way to set up endpoint health checks with smart alerting and multi-channel notifications, PingGuard handles uptime monitoring, SSL expiry alerts, and status pages — the core tools your on-call team needs. Free for up to 5 endpoints, with Slack and webhook integrations built in.