Most small engineering teams already run on-call in Slack, whether they planned to or not. Alerts land in a channel, someone posts "I'm on it", and the question everyone actually asks is "who is on call this week?". The tooling question is how much of that you formalise, and what you add so that a 3am alert reaches a person instead of a muted channel.

This guide is for teams of roughly 5 to 20 engineers. It covers the four parts of Slack on-call that matter at that size: knowing who is on call, paging that actually wakes someone up, a simple escalation path, and a handoff that does not depend on someone remembering to write it. It also covers the question a lot of small teams are asking right now, because two of the usual answers are going away.

Why small teams are re-choosing their on-call tool right now

For years the default advice to a small team was "start with Opsgenie or Grafana OnCall and keep incidents lightweight in Slack". Both of those defaults have changed:

Opsgenie is being retired. Atlassian stopped selling it to new customers on 4 June 2025 and ends support on 5 April 2027. Existing teams are being moved towards Jira Service Management or Compass. Our Opsgenie alternative page covers the timeline and the options.
Grafana OnCall OSS is archived. The open-source project went into maintenance mode in 2025 and has since been archived, and the cloud connection it used for SMS, phone and push notifications was turned off. The maintained route is Grafana Cloud IRM, billed per user. See Grafana OnCall alternatives.

That leaves small teams choosing between per-user incident platforms built for much larger organisations, and lighter Slack-native tools. The right answer depends less on features than on which of the four jobs below you actually need done.

Job 1: everyone knows who is on call, without asking

This is the job that matters most and the one most teams solve worst. The schedule lives in a spreadsheet, a calendar, or a paging tool that half the company has no login for, so people ask in a channel and wait.

In Slack the fix is a user group that always contains the current on-call engineer. Anyone can type @oncall-payments in any channel and reach the right person, with no lookup. Three things make it reliable:

The group updates itself at handover. If a person has to edit the group membership every Monday, it will be wrong by the third week. Tie the group to the rotation so membership changes at the exact handover time.
The channel topic says who is on call. People reading the channel see the name without mentioning anyone. Update the topic at the same moment as the group.
A heads-up before the handover. A reminder to the incoming engineer the day before (and a note in the team channel at handover) removes most "wait, is it me this week?" moments.

If your schedule already lives in PagerDuty or Opsgenie, you do not need to rebuild it in Slack: sync the user group from the existing schedule. We wrote up the details in syncing a Slack user group with the on-call schedule.

Job 2: paging that wakes someone up

A Slack notification is not a page. Do Not Disturb, muted channels, a phone in another room and Slack's own notification batching all stand between an alert and a human. For business-hours rotations (support duty, triage, release captain) that is fine. For anything that can break at night, you need a channel that keeps trying until someone acknowledges.

For a small team that usually means:

Escalating notifications: push, then SMS, then a phone call, repeating until someone acknowledges.
Delivery that does not depend on Slack. If Slack is having an outage, the page still has to land. This rules out "just @-mention the on-call person" as your only paging path.
Paging only the people who can be woken up. Most of the team needs to see the schedule; only the rota needs phone calls. Per-user pricing that charges for everyone who views the schedule is the main reason small teams overpay for on-call tools.

Which alerts page and which only post to a channel is a policy decision, not a tooling one. A good small-team default: customer-facing outages and data-loss risks page; everything else posts to the channel and waits for business hours.

Job 3: a simple escalation path

The common small-team setup, and the one in most of the threads where teams compare notes, looks like this: page the on-call engineer, and if nobody acknowledges within 10 minutes, page the next person. That is enough for most teams under 20 people. Resist the urge to build five levels.

Two refinements are worth having:

Escalate to a named backup, not "everyone". Paging the whole team at minute 10 teaches everyone to ignore pages. A secondary on-call, or the engineering lead for that week, is enough.
Different timeouts at night. Ten minutes during the day can be fifteen at night, when the on-call person needs time to wake up and get to a laptop.

Our escalation policy guide goes deeper, including how to test the policy before you need it.

Job 4: a handoff nobody has to write

The typical on-call handoff in a small team is a Slack message that says "quiet week, nothing major". It is rarely true and never useful. The handoffs that work are generated rather than written: a list of every alert that fired during the shift, grouped by alert name with a count, the incidents that were opened, and the ones still open. The outgoing engineer adds two or three sentences of context on top.

Generated handoffs fix two problems at once. The incoming engineer sees the noisy alerts that were acknowledged and ignored all week, which are exactly the ones likely to fire again. And the team gets a weekly record of which alerts are noise, which is the input you need to make on-call quieter. More on this in managing on-call handovers in Slack.

What a small-team Slack on-call setup looks like

Putting it together, a team of 5 to 20 engineers can run a complete on-call setup like this:

A weekly rotation per team, with a handover time that suits the team (Monday 10am beats Monday midnight).
A Slack user group such as @oncall-platform that always contains the current engineer, and a channel topic that shows the name.
Monitoring alerts routed into one alerts channel per team. Only the alerts that meet your paging policy create a page.
Paging by push, SMS and phone for the people on the rota, escalating to a named backup after 10 minutes.
Overrides done in Slack when someone is sick or on holiday, so the schedule and the user group stay correct.
A generated handoff posted to the team channel at the end of each shift.

If your team is small enough that 24/7 coverage itself is the problem, read 24/7 on-call coverage with a small team first: the rotation shape matters more than the tool.

How Pagerly does this

Pagerly is a Slack-native on-call tool built for exactly this setup, and it is priced per team rather than per user.

Rotations, user groups and overrides in Slack. Build the rotation in Pagerly, and the Slack user group and channel topic update at every handover. Reminders go out before a rotation changes. This is the Basic plan, at $19 per team per month.
Keep your existing schedule. If you still page from PagerDuty or Opsgenie, the Starter plan ($39 per team per month) syncs those schedules into Slack, and adds Jira, PagerDuty and Opsgenie two-way sync.
Paging when you need it. The on-call paging add-on is $4 per responder per month and is charged only for the people on the paging rota. It calls, texts and emails until someone acknowledges, runs escalation policies, raises incidents from AWS, Datadog, Sentry and 40+ tools, and runs on Pagerly's own infrastructure so pages land even when Slack is down.

There is a 10-day free trial, and adding Pagerly to Slack needs no credit card. See pricing or how rotations work in Slack.

FAQ

Can we run on-call entirely in Slack, without a paging tool?

For business-hours rotations, yes: a rotation, a user group and reminders cover it. For anything that can break overnight, add a paging channel that does not depend on Slack, because Slack notifications can be silenced and Slack itself can be down.

What is a good rotation length for a small team?

One week is the most common and the easiest to reason about. With fewer than five people, a week on call every month or so is already demanding; look at follow-the-sun or business-hours-only coverage before shortening the rotation.

How do we mention whoever is on call in Slack?

Use a Slack user group that a tool keeps in sync with the rotation, for example @oncall-backend. Mentioning the group reaches whoever is on call at that moment, and nobody needs to know the schedule.

We use Opsgenie. Do we have to move now?

Not today, but support ends on 5 April 2027 and migrations take longer than expected, mostly because of alert routing and escalation rules. Starting with the schedule and the Slack side first, then moving paging, keeps on-call working throughout.