Sending Pages to Slack and Teams: What You Gain and What You Lose
Adding a Slack or Teams channel as an alert destination is usually one of the first integrations a team sets up, and it's easy to see why — it's low-friction, everyone's already in the channel, and a page shows up with full context right where the team is already talking. It's also easy to stop there and assume the channel notification is doing the whole job. It isn't, and the gap matters more than it looks like at first.
What a channel notification actually gives you
A Slack or Teams card is genuinely good at a few things: it's visible without anyone needing to open a separate app, it shows up with context already attached — priority, who sent it, what changed — and it creates a shared view of what's happening for everyone in the channel, not just the person on call. For low-urgency notifications and for keeping a team generally aware of incident activity, that's exactly the right amount of friction.
What it quietly takes away
The problem is what a channel message doesn't do. Nobody has to acknowledge it. Nobody gets escalated to if it sits there unread for twenty minutes. And "it's in the channel" quietly becomes a stand-in for "someone's on it," which isn't the same claim at all — a message that eleven people saw and nobody actually owned is functionally the same as a message nobody saw. If a Slack notification is the only place a critical alert lands, there's no mechanism forcing a response, and no fallback if the one person who would normally catch it happens to have Slack muted.
The pattern that actually works
The fix isn't to stop using Slack or Teams — it's to stop treating the channel post as the primary delivery mechanism. The primary path should still page the on-call person directly, through a channel that supports acknowledgment and escalation if it's ignored. The Slack or Teams webhook runs alongside that as a mirror: everyone sees the same alert land in the channel at the same moment, and — this is the part that's easy to miss — the channel post can keep updating as the page's status changes. A page that gets acknowledged, escalated, or cancelled should update the same channel thread automatically, so the team's shared view stays accurate without anyone manually posting "handled, thanks" after the fact.
Setting it up without losing anything
In practice this means configuring the webhook to listen for more than just the initial page — page.sent, page.acknowledged, and page.escalated as separate events, each landing in the channel as its own update. PingParrot's webhooks support both Slack and Teams natively, with priority-coded cards (a critical page looks visibly different from a low-priority one) and separate payload formats for each platform, since Slack's block layout and Teams' MessageCard schema aren't interchangeable. The channel becomes a live, accurate log of what's happening — not a fire-and-forget notification that may or may not correspond to what's actually being done about it.
The actual test
Before trusting a Slack or Teams integration as part of an incident response chain, it's worth checking one thing directly: mute the channel, or leave it for a day, and see whether the person who needed to respond to a real page still got paged through a separate, acknowledgment-tracked channel. If the answer is no, the integration is providing visibility, which is valuable — but it isn't providing the thing an incident response chain actually needs, which is a guarantee that someone was notified and held accountable for responding.