Email is where alerts go to die. A 911 call notification that lands in an inbox between a newsletter and a meeting invite has failed at its one job. If your PBX can tell you something urgent happened, the message belongs where your team spends the workday, and for most IT teams in 2025 that means Slack.

This post covers the PBX alerts that earn a place in Slack, the channel structure that keeps people reading them, and the fields each message must carry so the reader can act without logging in anywhere.

Slack beats email for urgent alerts

Three properties make the difference:

Visibility. A channel is shared state. The moment a 911 alert posts, the whole channel sees the same message. With email, you’re hoping the right individual is at their desk.

Acknowledgment. A ✅ reaction or a threaded “on it, heading to floor 3” tells the rest of the channel the alert is owned. Email offers silence or a reply-all storm, nothing in between.

Mobile push. Channel notifications reach phones in seconds, and people leave Slack push enabled because the rest of their work arrives there. You disable email push the first week you’re buried in CC threads.

Keep email as a secondary path for compliance records, and route the urgent traffic to Slack.

The three alert classes that deserve a channel

Resist the urge to wire up each alert the PBX can produce. Three classes have proven their keep.

1. Emergency calls: #emergency-911

A 911 call from an internal extension should produce a message in this channel within a minute or two. Membership matters more than tooling here: front-desk and reception, facilities or security, the office manager at each site, and whoever owns Kari’s Law compliance. Skip the blanket IT invite and add the people who can walk to the caller’s location.

US multi-line systems face a legal requirement here, too: Kari’s Law requires direct 911 dialing and on-site notification. A Slack channel with the right members, fed within 1–2 minutes of the call, is a clean way to operate the notification half of that obligation. See our emergency 911 alert page for the compliance details.

2. Fraud and misuse: #telecom-fraud

The patterns worth alerting on are well known: international calls after business hours, calls to premium-rate destinations, sudden bursts of short outbound calls from one extension, and traffic to countries your business has no reason to call. Membership: telecom admin, IT security, and a manager who can authorize blocking a route at 2am. Toll-fraud losses compound by the hour, so this channel should page like it means it: turn on all-message notifications instead of the default, which pings on mentions alone.

3. Operational thresholds: #phone-ops

The daytime workhorse: missed calls exceeding N this hour, queue abandon rate spiking, a trunk group hitting capacity, or the collector losing contact with the PBX. Membership: the team that staffs the phones plus their supervisor. These alerts catch a bad morning at 10:30 instead of in next month’s report.

Channel design: a noisy channel gets muted

The fastest way to ruin the setup above is one #pbx-alerts channel carrying it all. Within a month your team mutes it, and the mute takes the 911 alerts down with the missed-call noise. Rules that hold up:

  • One channel per urgency class, none per alert type. Three channels fit most orgs.
  • Match notification settings to urgency: all-message push for #emergency-911 and #telecom-fraud, default settings for #phone-ops.
  • Tune thresholds until a channel averages a handful of messages a day at most. If #phone-ops fires twenty times a day, fix the threshold before questioning the team.
  • If an alert keeps firing on a known condition, fix or suppress it within the week. Each alert your team learns to scroll past trains them to scroll past the next one.

Write messages people can act on without logging in

An alert that says “Emergency call detected” forces a login to find out where. By the time someone has authenticated, the moment has passed. Each message should carry the facts inline:

🚨 911 CALL - Main office
Extension: 4217 (Sarah K., 3rd floor east)
Time: 14:32:08
Dialed: 911
Trunk: PRI-2

The same principle applies to fraud alerts (extension, destination number and country, time, duration, estimated cost so far) and threshold alerts (current count, the threshold, the hour, which queue). Apply one test: the reader should be able to take the correct physical action (walk to the floor, call the carrier, pull someone off lunch) from the message alone. If they can’t, add fields.

Zapier as the escape hatch

Slack is the default destination, and some teams live elsewhere. If your security team works in a SIEM, your facilities team in Teams, or your on-call rotation in PagerDuty, route through Zapier: the PBX alert triggers a zap, and the zap fans out to whatever the receiving team reads. SMS and automated voice calls remain the right channel for after-hours emergencies, when the apps are closed and the phones sit on nightstands. Treat Slack as the default and route around it where a team lives somewhere else.

Test the path each quarter

Alert paths rot in the background. A Slack app token expires, a channel gets archived in a workspace cleanup, the one person in #emergency-911 who sat near the door changed jobs. Put a recurring item on the calendar: once a quarter, place a test call against each alert rule (use your 933 test service or a designated test number for the 911 path, and coordinate so the test triggers no dispatch), confirm the message arrives within the expected 1–2 minutes, and confirm the people in the channel still work there. The habit costs fifteen minutes, four times a year, and the first failed test repays a decade of them.

Where PBXDom fits

The setup above assumes something watches your call records and fires the webhooks, and that part is PBXDom’s job. It reads CDR/SMDR output from Cisco, Avaya, Mitel, Panasonic, 3CX, and Asterisk/FreePBX systems (end-of-life models still running in a closet included) and sends 911, fraud, and threshold alerts to Slack, email, SMS, automated voice call, or Zapier within 1–2 minutes of the triggering call. The collector installs in about 15 minutes; the onboarding guide walks through it.