If your company lives in Microsoft Teams, your on-call schedule should live there too. An on-call schedule in Microsoft Teams means anyone in a channel can see who is on call right now, reach that person with one mention, and trust that the answer is correct without opening a separate tool or a stale spreadsheet. This guide covers the options Teams gives you out of the box, where each one breaks down, and a step-by-step setup that works for engineering, IT and support teams of any size.

The short version: Teams can display a schedule and notify whoever is on shift, but it was built for frontline shift work, not for paging engineers at 3am. Most teams end up combining a native Teams feature for visibility with a dedicated on-call layer for escalation and paging. Below we walk through how to decide, how to set it up, and the mistakes that quietly break on-call in Teams.

Why run your on-call schedule in Microsoft Teams at all

The best on-call schedule is the one people actually check. When the schedule lives in a separate paging tool, a wiki page or a shared calendar, the people who need it most (a support agent with an angry customer, a product manager who just saw a dashboard go red, a new engineer in their first week) do not know where to look. They ask in a channel, someone guesses, and the wrong person gets pinged.

Putting the schedule where the conversation already happens fixes three recurring problems:

Discovery. "Who is on call for payments?" becomes a question the channel can answer itself, instead of a question that waits for a manager to wake up.
Routing. A mention that always resolves to the current responder removes the guesswork of picking a name from last week's rota.
Accountability. When handovers, acknowledgements and incident updates happen in a channel, there is a visible trail. Retrospectives get easier because the timeline already exists.

For organisations standardised on Microsoft 365, there is also a practical argument: Teams is already approved, already on every laptop and phone, and already tied to your identity provider. Adding the schedule there is easier to get through security review than introducing another chat surface.

What Microsoft Teams offers natively for on-call

Teams does not have a feature literally called "on-call schedule", but three native building blocks get you part of the way. Understanding exactly what each one does, and does not do, saves you from discovering the gaps during an incident.

The Shifts app

Shifts is Microsoft's scheduling app inside Teams. Managers create schedules, assign shifts to people, group shifts by team or role, and let people swap or request time off. Microsoft documents it as a tool for frontline workers, and admins manage it from the Teams admin center (see Manage the Shifts app for your organization on Microsoft Learn).

For on-call, Shifts gives you a visible calendar of who is scheduled and when. What it does not give you is anything that happens when a shift owner fails to respond. There are no escalation levels, no acknowledgement tracking and no phone call when a critical alert fires overnight. It is a roster, not a pager.

Tags and shift-based tags

Teams tags let you group people under a label such as @db-oncall and mention the whole group at once in a channel post or chat. Microsoft's admin documentation, Manage tags in Microsoft Teams, explains how owners and admins control who can create and manage them.

The interesting variant is shift-based tags. When enabled, the Shifts app assigns tags automatically based on the schedule and the shift group name, so a tag such as @EngineerOnCall reaches only the people who are on shift at the moment it is used. Microsoft describes the setup in Turn on shift-based tags in Microsoft Teams. This is the closest thing Teams has to a "mention whoever is on call" primitive.

The limits matter. Tags work within a single team, so people outside that team cannot be reached through it. They notify like any other mention, which means a busy channel or a muted phone can swallow them. And they inherit every weakness of the underlying Shifts schedule: if nobody updated the schedule after a swap, the tag points at the wrong person.

Workflows and webhooks for alerts

Most teams want monitoring alerts to land in a Teams channel. Historically that meant Office 365 connectors and incoming webhooks. Microsoft has retired connectors in Teams and moved alert posting to the Workflows app, which is built on Power Automate; Tony Redmond's overview of replacing retired connectors with Teams Workflows is a useful summary of what changed.

If your alerting still depends on an old connector URL, check it today. A dead webhook does not page anyone; it just stops posting, and the first sign is usually a customer report. Workflows can post alerts to a channel, but on their own they do not know who is on call or what to do if nobody reacts.

Where native Teams on-call breaks down

Teams covers visibility well. Where it falls short is the part of on-call that matters most when things go wrong: making sure a human actually responds.

No escalation when the primary does not answer

Real incidents follow a predictable pattern. The alert fires, the primary is asleep, in a tunnel or on a flight, and nothing happens for twenty minutes. A proper on-call setup escalates automatically to the secondary, then to a manager, after a defined wait. Shifts and tags have no concept of "if nobody acknowledges within five minutes, try the next person". You can approximate it with Power Automate, but you are now maintaining a homegrown paging system that nobody tests until it fails.

Notifications that are easy to miss

A Teams mention is a chat notification. It respects Do Not Disturb, focus modes and phone settings, which is exactly what you want during the day and exactly what you do not want for a production outage at night. Serious paging needs a channel that is designed to wake someone up: a phone call, an SMS, or a push notification that bypasses quiet hours, repeated until someone acknowledges.

Rotation logic is manual

Shifts is good at "Priya works Tuesday 9 to 5". It is less good at "rotate weekly through these six engineers, hand over on Monday at 10am in each person's local time, skip anyone on leave, and let people swap without asking a manager". Engineering rotations are rule based, and maintaining them by hand in a shift calendar is where schedules drift away from reality.

No link between the schedule and the work

On-call is not only incidents. The person on call often owns the support queue, the Jira triage column or the deploy approvals for the week. When the schedule is just a calendar, that ownership has to be reassigned by hand every rotation, and it rarely is.

How to set up an on-call schedule in Microsoft Teams, step by step

The setup below works whether you stay fully native or add a dedicated on-call tool. Steps one to four are tool agnostic; steps five onward are where a purpose-built layer earns its place.

Step 1: Decide what you are covering

Write down, in one sentence each, the services or queues that need a responder and the hours they need one. "Customer-facing API, 24/7" is different from "internal IT helpdesk, business hours in two time zones". This list becomes your set of schedules. Resist the urge to create one giant rotation for everything; a single schedule that covers payments, infrastructure and the data pipeline guarantees that whoever is on call is out of their depth for two thirds of the pages.

Step 2: Pick a rotation pattern that fits your team size

For teams of four to eight engineers, a weekly rotation with a primary and a secondary is the common starting point. Smaller teams usually need longer gaps between shifts and a business-hours-only primary with a lightweight out-of-hours policy. Teams split across continents can use follow-the-sun handovers so nobody is paged overnight. Our guide to building a fair on-call rotation and schedule covers the trade-offs between these patterns in more depth.

Whatever you choose, write the handover time and time zone into the schedule itself, not into a wiki page. "Handover Monday 10:00 Europe/London" removes an entire class of "I thought you had it" incidents.

Step 3: Create one Teams channel per on-call scope

Give each schedule a home channel, for example #oncall-payments or #oncall-platform. Pin a short post at the top that explains what the channel is for, how to reach the current responder, and what counts as urgent. Route alerts for that service into the same channel so context accumulates in one place. Keep incident chatter for major incidents in a dedicated incident channel, so the on-call channel stays readable.

Step 4: Make "who is on call" answerable in one step

This is the most important step, and it is where most setups fall short. Someone in the channel should be able to reach the current responder with a single action, without checking a calendar. Natively, that means shift-based tags. With a dedicated tool, it usually means a command or a mention that always resolves to whoever is currently on call. Test it: ask someone outside the team to find and contact the on-call engineer for a given service. If it takes more than thirty seconds, fix it before you go live.

Step 5: Add escalation and real paging

Define what happens when the primary does not acknowledge. A reasonable default for a production service:

Page the primary immediately through a channel that can wake them (push notification, SMS or a phone call).
If there is no acknowledgement in five minutes, page the secondary.
If there is still no acknowledgement in fifteen minutes, page the engineering manager or incident lead.
Post every step into the on-call channel so the trail is visible.

This is the piece native Teams does not provide. A dedicated on-call tool handles it without custom flows. Pagerly, for example, runs on-call schedules, rotations and incidents inside Slack and Microsoft Teams, and its on-call paging calls, texts and emails responders until someone acknowledges, following the escalation policy you define. Paging runs on Pagerly's own infrastructure rather than the chat platform, so a page still lands if the chat tool itself is having a bad day.

Step 6: Connect alerts to the schedule, not to people

Route monitoring alerts to the on-call schedule, never to a named individual. Alerts sent to a person stop working the day that person goes on holiday or leaves the company. When alerts target the schedule, the right responder gets them automatically after every handover. Review your alert sources (uptime monitors, APM, cloud provider alarms, error trackers) and confirm each one points at a schedule or service, and that none of them still depends on a retired connector.

Step 7: Automate the handover

A handover should not depend on someone remembering to post. Set up an automatic message in the on-call channel at each handover with the outgoing and incoming responders, so the team sees the change and the incoming engineer gets a nudge. Encourage the outgoing engineer to reply in the thread with anything still open: noisy alerts, ongoing incidents, risky deploys scheduled for the week.

Step 8: Make swaps and overrides self-service

Life happens. Someone gets sick, someone has a wedding, someone's child has a school play. If swapping a shift requires a manager to edit a calendar, people either skip the swap and miss pages, or they swap informally and the schedule lies. Let engineers create overrides themselves, and have the tool post the override in the channel so everyone knows who is actually covering.

Native Teams vs a dedicated on-call tool: how to choose

Not every team needs a paging tool on day one. Here is a simple way to decide.

Native Shifts and tags are enough when

Coverage is business hours only, and an out-of-hours issue can wait until morning.
The "on-call" role is really a rota for a queue (helpdesk, customer escalations, release captain), not incident response.
Everyone who needs to reach the responder is a member of the same team.
Missing a mention for an hour is annoying but not costly.

You need a dedicated on-call layer when

You support customer-facing systems outside business hours.
You have an uptime commitment or SLA that a missed page would breach.
You need escalation, acknowledgement tracking and a record of response times.
Rotations are rule based (weekly, follow-the-sun, primary and secondary) and change often.
Other teams, or people outside your Teams team, need to find and page your responder.

A pragmatic middle path is to keep Teams as the place people see and talk about on-call, and let a dedicated tool own the schedule logic, escalation and paging. That way the experience stays native to Teams while the critical path does not depend on chat notifications.

Common mistakes with on-call in Microsoft Teams

Treating a channel mention as a page

A mention in a busy channel at 2am is not a page. If an alert matters enough to post, it matters enough to escalate when nobody reacts. Decide which alerts are urgent, and make sure those ones reach a phone in a way that cannot be silenced by a focus mode.

Letting the schedule drift

Schedules rot when updates are manual. Every informal swap that never made it into the calendar is a future incident where the tag points at someone on a beach. Self-service overrides and automatic handover posts are the cheapest fix.

One rotation for everything

A single company-wide rotation means the database expert gets paged for frontend errors and the frontend engineer gets paged for replication lag. Split schedules by service ownership as soon as you have enough people to staff them.

No record of what happened

If acknowledgements and escalations happen outside Teams, or not at all, you cannot answer basic questions in a retrospective: how long did it take to respond, who was paged, and did the escalation policy work? Keeping incident updates in a channel, ideally driven by an incident response bot that records the timeline for you, makes the post-incident review much shorter.

Forgetting the humans

Microsoft Teams makes on-call visible, which is good, but visibility also exposes imbalance. If the same two people take most of the pages, the schedule will show it. Review page volume per person monthly, fix noisy alerts, and rebalance rotations before burnout turns into attrition.

A sample on-call setup for a 6-person platform team

To make this concrete, here is a setup that works well for a typical platform team running a customer-facing service in Microsoft Teams.

Schedules: one weekly primary rotation and one weekly secondary rotation, offset by one position so nobody is primary and secondary in the same week.
Handover: Monday 10:00 in the team's main time zone, with an automatic post in #oncall-platform naming the incoming primary and secondary.
Alerts: uptime and APM alerts routed to the primary schedule; low-urgency alerts post to the channel only, high-urgency alerts page.
Escalation: primary immediately, secondary after five minutes, engineering manager after fifteen.
Reaching the responder: a single mention or command in the channel that resolves to the current primary, pinned at the top of the channel.
Overrides: any engineer can cover a shift for someone else; the override is announced in the channel automatically.
Review: a monthly look at pages per person, time to acknowledge and the noisiest alerts.

With six people, each engineer is primary roughly one week in six, which keeps load sustainable while giving everyone enough practice to stay sharp.

Key takeaways

An on-call schedule in Microsoft Teams works best when anyone can reach the current responder in one step, without checking a calendar.
Shifts and shift-based tags give you a native roster and a "mention whoever is on shift" option, but no escalation, acknowledgement or wake-up paging.
Office 365 connectors are retired in Teams; check that every alert source has moved to Workflows or a dedicated integration.
Route alerts to schedules, not people, and automate handovers and overrides so the schedule never drifts from reality.
For out-of-hours production support, pair Teams visibility with a dedicated on-call layer that pages by phone and escalates automatically.

Microsoft Teams is a great front door for on-call. It is where your colleagues already ask questions, where alerts can land with context, and where incident updates are visible to everyone who cares. Native features like Shifts and shift-based tags are a reasonable start for business-hours rotas and queue ownership.

For anything that has to work at 3am, treat Teams as the place people see on-call and a dedicated tool as the thing that makes sure someone responds. If you want both in one place, Pagerly runs on-call schedules, rotations, escalation and incidents inside Microsoft Teams and Slack, with a 30-day free trial that needs no credit card. Plans are priced per team rather than per seat, with paging charged only for the responders who should actually be woken up; the details are on the pricing page.