How to set up on-call for the first time (a practical guide)

Most teams' first version of "on-call" is one person watching a Slack channel and hoping they notice. It works right up until the person who watches everything goes on holiday, or the alert fires at 2 a.m. and no one sees it for an hour. If you've hit that point, it's time to set up real on-call — and you can do it in an afternoon without over-engineering it.

Here's a practical, no-nonsense guide for a small team going from zero to a working on-call setup.

Step 1 — Decide what you're actually paging for

Before schedules and tools, answer one question: what is worth waking someone up for? Be strict. A good starting rule:

• Page (wake someone): customer-facing outage, data loss risk, payments down, security incident.
• Notify (don't wake anyone): elevated error rates that aren't customer-visible, a single failing background job, capacity warnings.
• Ignore / ticket: anything a human doesn't need to act on within the hour.

Write this down. Half of on-call pain comes from paging on things that shouldn't page. (More on this: alert fatigue is a design problem →)

Step 2 — Map your services and owners

List the handful of things that can break and matter — "Checkout API," "Auth," "Payments," "Web." For each, note who understands it. You don't need a perfect service catalog; you need to know who to route an alert to for each area. Start with 3–6 services, not 30.

Step 3 — Build a fair rotation

A rotation is just "who is the first responder right now." Keep the first one simple:

• Weekly rotation for most small teams (one person per week) — enough continuity to catch patterns, short enough to not burn out.
• Minimum 3–4 people in the rotation. With fewer, on-call becomes a punishment and people leave. If you don't have four, do a lighter "business-hours only" rotation until you do.
• Follow-the-sun only if you have engineers in multiple time zones — then you can avoid night pages entirely by handing off across regions.
• Overrides for holidays and sick days, so no one is silently on-call when they're unavailable.

Fairness matters more than cleverness. An unfair rotation is the fastest way to lose the trust (and the people) that on-call depends on.

Step 4 — Set up escalation

Escalation answers: what happens when the first responder doesn't ack? A sane default:

1. Level 1 — page the on-call engineer. If not acknowledged in ~5 minutes…
2. Level 2 — page a backup (the previous week's on-call, or a lead).
3. Level 3 — page the engineering manager.

The whole point is that no alert can fall through the cracks because one person's phone was on silent. Set the timeouts short — 5 minutes to escalate is better than 15 when something is actually down.

Step 5 — Pick notification channels that actually reach people

Email alone will not wake anyone. Layer channels by urgency:

• High urgency: push notification + SMS + a phone call. (In India, make sure your SMS is DLT-compliant, or it silently won't deliver — and consider WhatsApp, which people actually check.)
• Low urgency: Slack + email.
• Quiet hours: let people set them for low-urgency alerts, but never for true pages.

Test it. Genuinely — trigger a fake page and confirm your phone rings. The first real incident is the wrong time to discover the phone-call channel was never configured.

Step 6 — Write runbooks for the top 5 alerts

For your most common alerts, write a short runbook: what it means, what to check first, how to fix it, and who to escalate to. Five good runbooks beat a wiki no one opens. A responder at 3 a.m. doesn't need a novel — they need the three commands that fix it. (How to write a runbook that gets used →)

Step 7 — Review and tune (the step everyone skips)

After a couple of weeks, look at your alerts and ask:

• Which alerts paged but didn't need a human? Downgrade them to notifications. This is the single highest-leverage thing you can do for on-call quality.
• Which incidents had no runbook? Write one.
• Was the rotation fair? Adjust.

On-call is not "set up once." It's a loop: page → resolve → tune so it pages better next time.

What "good" looks like after a month

• Every service has an owner and a route.
• No alert can go unacknowledged — escalation guarantees a human.
• Pages are rare and real; noise goes to Slack, not to phones.
• The top alerts have runbooks.
• People trust the rotation because it's fair and quiet.

Don't over-build it

You do not need SLOs, error budgets, and a 12-step incident command process on day one. You need: a fair rotation, working escalation, channels that reach people, and runbooks for your top alerts. Add sophistication as you grow — not before.

If you'd rather not wire schedules, escalation and multi-channel paging by hand, that's exactly what an on-call platform is for. PagerCo gives you rotations, escalation policies, and omnichannel paging (WhatsApp, SMS, voice, Slack, push) out of the box — with a free trial to set it up in an afternoon.