The PagerDuty Microsoft Teams integration gets incident notifications into Teams channels and lets responders acknowledge and resolve from there. It does not turn Teams into your on-call tool. It will not answer "who is on call for payments?" from a channel, it cannot post into private or shared channels, and it needs three different admins to set up. If your company runs on Teams, you should know exactly where that line falls before you design your incident process around it.

This guide explains what the integration actually does, what it needs from your Microsoft and PagerDuty admins, the limits that catch teams out, and a setup checklist that avoids the common mistakes. It also covers the gaps most teams end up filling themselves: on-call visibility, mentionable responders and incident channels that people outside engineering can find.

What the PagerDuty Microsoft Teams integration does

At its core the integration is a notification and action bridge. When an incident fires on a PagerDuty service that you have mapped to a Teams channel, PagerDuty posts a card with the incident details into that channel. As the incident changes (acknowledged, reassigned, escalated, resolved), PagerDuty adds progress updates, so the channel keeps a running record.

Incident cards and actions

Channel members can view and create incidents from Teams, and take actions such as acknowledge and resolve without switching to the PagerDuty web app. This is the part most teams care about: the responder sees the card in the channel where people are already talking, and can take ownership in one click.

There is a catch. To act on an incident, a responder must link their Teams account to their PagerDuty account. Unlinked users can see the card, but when they press a button the integration has no idea who they are in PagerDuty. Expect a round of "it says I need to link my account" messages on the first real incident unless you get everyone linked during setup.

Conference bridges and private chats

If you grant the optional calendar permission, PagerDuty can create a calendar event with an attached Teams meeting and use it as the incident's conference bridge. Responders with linked accounts are added automatically.

Through Teams actions in PagerDuty Incident Workflows, it can also create a private Teams chat for an incident and add linked responders to it. Note the wording: these are group chats, not channels. That distinction matters later.

Bot commands

The PagerDuty app in Teams is driven by a handful of commands. The ones you will meet during setup are:

connect: map a PagerDuty service to the current channel.
linkUser and unlinkUser: link or unlink your Teams identity and your PagerDuty user.
open: open your PagerDuty account.
graphAuth: authenticate individually when your tenant uses delegated permissions.
appconnect: complete the Microsoft Graph setup.

That is the full shape of it. Notice what is not on the list: there is no command that answers who is on call, no mentionable on-call handle, and no automatic channel per incident.

What it needs before it works: the three-admin setup

The biggest surprise for teams setting up the PagerDuty Microsoft Teams integration is not technical. It is organisational. Three separate roles have to say yes, and in larger companies those are three different people, often in different departments.

1. A PagerDuty admin

Someone with admin rights in PagerDuty (Admin, Global Admin or Account Owner) authorises the connection between your PagerDuty account and your Microsoft tenant. If an engineer with a manager role tries this, it fails with an authorisation error.

2. A Microsoft Teams admin

Teams admins control which third-party apps are allowed in your tenant. If your organisation blocks third-party apps by default, the PagerDuty app has to be allowed in the Teams admin center first. Microsoft documents how this works in its guide to managing apps in the Teams admin center. Many companies also use app setup policies to pin approved apps for specific groups, which is a good way to make the PagerDuty app easy to find for on-call engineers.

3. A Microsoft admin for Graph API consent

Features like meetings and private chats rely on Microsoft Graph, which means someone has to consent to Graph permissions. You choose between two models:

Application permissions: one-time admin consent, after which PagerDuty can act in the background. Best for automation such as auto-creating meetings and chats.
Delegated permissions: each user authenticates individually with graphAuth, and PagerDuty acts on their behalf. Stricter, but more friction for responders.

If you have not dealt with this before, Microsoft's overview of Graph permissions explains the difference, and its guide on granting tenant-wide admin consent shows what your identity team will actually click. Security teams frequently push back on application permissions for calendar access, so raise it early instead of discovering it the week you go live.

Who can map services to channels

Once installed, PagerDuty admins can map services to channels from the PagerDuty web app or from Teams. Users with a manager role (base or team) can map services only from inside Teams. In practice, let team leads own their own channel mappings from Teams so the central admin is not a bottleneck.

The limits that catch teams out

None of these are hidden, but they rarely come up until an incident is underway. Plan around them up front.

No private or shared channels

PagerDuty states that its application cannot currently be integrated with private or shared channels in Microsoft Teams. This hurts more than it sounds. Plenty of organisations put security, payments or customer-specific work in private channels, and use shared channels to work with partners and vendors in other tenants. Those are exactly the places a sensitive incident should be discussed, and the integration cannot post there.

The suggested workaround is the private chat created through Incident Workflows. That keeps the conversation contained, but chats are not channels: they do not have tabs, they are harder to find later, they do not show up in a team's channel list, and someone who joins mid-incident has no obvious place to look.

Notification is not visibility

The integration tells a channel that an incident exists. It does not tell anyone who is on call when there is no incident. That is the gap support, product and customer success teams feel most. When a customer reports something odd that has not triggered an alert, the person in Teams has two choices: open PagerDuty (which they may not have a seat for) or ask in the channel and hope someone knows.

No mentionable on-call responder

Teams supports tags, which work like @mentions for a group. But the PagerDuty integration does not keep a Teams tag in sync with your PagerDuty schedule. So "@payments-oncall" either does not exist or points at whoever someone last added manually. Stale tags are worse than no tags: they confidently page the wrong person.

EU accounts use a different app

If your PagerDuty account is hosted in the EU service region, you need the separate "PagerDuty EU" app in Teams. Installing the standard app and wondering why authorisation fails is a common first hour.

Legacy connector migration

The older connector-based app is no longer available for new installs. If you still have it, PagerDuty's guidance is to remove all legacy connectors and the legacy app from each team before moving to the current app. On a tenant with dozens of teams, that is a migration project, not a toggle. Inventory where the old connectors live before you start.

Account linking expires and confuses people

Authorisation errors are often caused by an insufficient PagerDuty role or an expired link, and the fix is to generate a fresh link from Teams. Put this in your on-call onboarding doc. A new engineer at 3am should not be debugging OAuth.

PagerDuty in Teams vs PagerDuty in Slack

Teams shops often hear that "PagerDuty works great in Slack" and expect the same in Teams. The two integrations are separate apps, built against different platforms, and they do not have identical feature sets. Treat the Teams integration on its own terms and test the specific workflows you rely on, rather than assuming parity with what a Slack-using friend describes.

The platform difference also matters. Slack user groups and Teams tags are both mentionable groups, but they are managed differently, and Teams has stricter tenant-level controls over which apps can do what. That is good for security, and it is also why the Teams rollout tends to take longer. If you also run Slack somewhere in the company, our guide to the PagerDuty Slack integration covers that side.

How to set up the PagerDuty Microsoft Teams integration without the usual pain

Here is a sequence that works for most engineering organisations. It front-loads the approvals so the technical steps go quickly.

Step 1: Decide your channel model first

Before anyone installs anything, decide which PagerDuty services map to which Teams channels. A good default:

One standard channel per owning team, for example "payments-incidents", mapped to that team's services.
No mapping into general team channels where incident cards will drown real conversation, or get muted.
A clear rule for sensitive services that live in private channels today, since the integration cannot post there. Either move incident notifications for those services to a standard channel with a neutral name, or rely on Incident Workflows private chats and document that choice.

Step 2: Get the three approvals in one meeting

Book thirty minutes with the PagerDuty admin, the Teams admin and the identity admin who handles Graph consent. Agree on application or delegated permissions, whether to grant calendar access, and whether the app gets pinned through an app setup policy. Doing this in one conversation turns a two-week email chain into an afternoon.

Step 3: Install and connect

Install the correct app (standard or EU) for your PagerDuty region. Have the PagerDuty admin authorise the account connection, then complete the Graph setup. In each mapped channel, run connect and choose the services.

Step 4: Link every responder before go-live

Send everyone on a PagerDuty schedule a short message asking them to run linkUser. Then check: pick a test service, trigger a low-urgency incident and ask each responder to acknowledge it from Teams. Anyone who cannot is not linked. This is the single most valuable step in the whole rollout.

Step 5: Run a game day

Trigger a realistic test incident during working hours and walk through the full flow: card arrives, responder acknowledges, meeting is created, a second responder is added, incident resolves. Time each step. Write down every "where do I click?" moment and fix it in your runbook. Google's SRE book chapter on managing incidents is a good reference for what a clean incident flow should look like, regardless of tooling.

Step 6: Document the gaps explicitly

Write a short "PagerDuty in Teams: what it does not do" note for your support and product teams. Tell them how to find who is on call, how to page someone when there is no incident yet, and where to discuss incidents on services that live in private channels. Unwritten gaps become 2am DMs.

Filling the gaps: on-call visibility and paging inside Teams

Most teams that run PagerDuty in Teams eventually add a layer for the things the integration does not cover. The requirements are consistent across companies.

"Who is on call?" answered in Teams

Anyone in the company should be able to find the current responder for a service from inside Teams, without a PagerDuty seat. That can be as simple as a pinned tab or a bot that answers the question, as long as it reads from the real schedule and not from a spreadsheet someone updates on Mondays.

Tags that follow the schedule

The mention people type, such as @payments-oncall, should always resolve to whoever is on shift right now. That means the group membership has to be updated automatically at every handover and every override, including the overrides someone made at 11pm on a Friday. Our guide on running an on-call schedule in Microsoft Teams goes through tags, Shifts and how to keep them current.

Paging when there is no alert

Some of the most important pages start with a human, not a monitor: a support agent who sees five tickets about the same checkout error. They need a way to page the on-call engineer from Teams that goes through escalation, rather than a DM that may sit unread. If you need this, look for a tool that supports escalation with acknowledgement, and phone or push notifications for the responder. See how on-call paging works in Pagerly for one approach.

Incident spaces people can find

When an incident is big enough to need a dedicated space, a channel created for that incident (with the details, the owner, and a clear name) is easier to find and to review afterwards than a group chat. An incident response bot can create that space, post updates back to the ticket, and keep a timeline for the retrospective.

Where Pagerly fits

Pagerly runs on-call, rotations, incidents and tasks inside Slack and Microsoft Teams. If you already use PagerDuty, Pagerly can sync your PagerDuty schedules so the on-call information shows up where your team works, while PagerDuty keeps doing what it does well. If you would rather not keep two tools, Pagerly can also hold the rotations and escalation itself.

For a Teams-first company, that covers much of the layer described above: rotations and schedules kept current in the place people already work, incidents run in Teams, and paging with escalation when you want it. Pricing is per team rather than per seat (paging is an optional per-user add-on), so a support agent who only needs to know who is on call does not need a paging licence. You can try it free for 30 days, and adding it to Teams needs no credit card. Plan details are on the Pagerly pricing page.

Common questions about PagerDuty and Microsoft Teams

Can PagerDuty post incidents into a private Teams channel?

Not at the time of writing. PagerDuty says its app cannot be integrated with private or shared channels. The closest option is a private group chat created through Incident Workflows.

Do responders need a PagerDuty account to act from Teams?

Yes. Acting on an incident card requires a linked PagerDuty user. Anyone can read the card in a channel they belong to, but buttons only work for linked accounts.

Can I see who is on call from Teams with the PagerDuty app?

The integration focuses on incidents. It does not provide an on-call lookup command or a mentionable group that tracks the schedule. Teams that need that usually add a bot or sync layer that reads from PagerDuty.

Does the integration create a Teams channel per incident?

No. It can create a Teams meeting as a conference bridge (with calendar permission) and private chats through Incident Workflows, but not a dedicated channel.

We use the EU PagerDuty region. Is anything different?

Yes. Install the "PagerDuty EU" app instead of the standard one.

Key takeaways

The PagerDuty Microsoft Teams integration is good at one job: incident cards in channels, with acknowledge and resolve actions for linked users.
Setup needs three approvals (PagerDuty admin, Teams admin, Graph consent). Get them in one meeting.
Private and shared channels are not supported. Decide where sensitive incidents go before go-live.
Link every responder and test acknowledgement before the first real incident.
It does not answer "who is on call?", keep tags in sync, or create incident channels. Plan a layer for that, whether built in-house or bought.
Write down the gaps for non-engineering teams so they know how to reach on-call when there is no alert.

Conclusion

Connecting PagerDuty to Microsoft Teams is worth doing. Incident cards in the right channel, with acknowledge and resolve in place, shave real minutes off the start of every incident. But it is a notification bridge, not an on-call system for Teams. The teams that are happiest with it are the ones that understood that from day one: they designed a clean channel model, cleared the admin approvals early, linked every responder, and filled the visibility and paging gaps on purpose. Do those four things and Teams becomes a calm place to run incidents, instead of a place where people ask who is on call and wait.