Telegram VoIP for ops: bypass-DND alerting that recipients don't hate
Why a Telegram VoIP call is the cheapest reliable way to wake on-call without per-message carrier fees, what it costs at scale (spoiler: nothing) and the failure modes you have to wire around.
- By
- WardenPoint team
- Published
- May 21, 2026
- min read
- 4
Marek from our team missed a production fire at 04:12 last August. His phone was a meter from his head. Vibrations off. Focus mode active from 22:00 to 07:00. Slack, Teams, email, even an SMS from Twilio — everything fell through the same silence filter he'd built over a year to stop reacting to every CI bot ping. The outage resolved itself at 04:47 when someone from another shift in a different timezone noticed the anomaly and manually restarted the service. Marek heard about it in the morning.
After a week of post-incident analysis we added one channel to the chain that we'd previously treated as a gadget — a Telegram VoIP call. Since then Marek hasn't missed a fire. The rest of this post explains why a bot-originated VoIP call is the cheapest reliable way to wake an on-call engineer, what fails when it fails, and what to wire around it.
Why Telegram VoIP wakes people
A regular Telegram text message arrives silently if the user has Do Not Disturb on. A push notification has the same fate. The phone vibrates, maybe — but the on-call engineer learned years ago to silence vibrations because their phone goes off too much.
A Telegram VoIP call rings. The full ringtone. It bypasses Do Not Disturb in the same way that a regular phone call does on iOS and Android (with the "Allow Calls From Everyone" or equivalent setting). Telegram explicitly treats VoIP traffic as call traffic, not as messaging — so the OS treats it as a call too.
That's the whole pitch in one paragraph. The on-call person can't sleep through it. They can ignore the first ring (escalation policy then picks up), but they can't pretend they didn't hear it.
Cost at scale
| Channel | Per page cost |
|---|---|
| Twilio voice call (US number, US recipient) | ~$0.013/min, $0.025 setup, typical 30s call ≈ $0.04 |
| Twilio SMS (US to US) | $0.0079 per segment |
| Telegram VoIP | $0 |
A team paging 200 times a month spends $8 on Twilio voice or $1.50 on SMS. Telegram VoIP is free at any volume. The cost argument isn't life-changing at small scale — it matters because it removes a budget line.
Failure modes you have to handle
Telegram VoIP isn't infallible. Three things can go wrong:
1. The recipient turned off Telegram notifications
If the user has Telegram itself muted (not just the chat with the bot), the call WILL come through. If they've turned off VoIP specifically (settings → notifications → calls), nothing fires. The escalation chain has to assume the first attempt might be silent and route to a backup channel.
Pattern that works:
1. Telegram VoIP call (free, loud)
2. Wait 60 seconds
3. SMS (paid, also loud, different network path)
4. Wait 60 seconds
5. PSTN voice call (paid, loudest, most expensive)
6. Wait 90 seconds
7. Secondary on-call: same chain
The first three steps cost ~$0.01 each on the paid side, the first step is free. So the typical wake-up is ~$0.02 if the first VoIP call doesn't ack, and $0 if it does.
2. Telegram itself is down
Rare but it happens. The escalation chain has to NOT depend on Telegram for the second-attempt fallback. SMS + PSTN must go through carriers, not Telegram bridges.
3. The recipient is in a country where Telegram is blocked
Russia, Iran, China, occasionally Pakistan and a few others. The user might have Telegram via VPN, but VPN-Telegram is unreliable for inbound calls. For these recipients, treat Telegram as a "best effort" attempt 1 and rely on SMS / PSTN as the load-bearing wake-up.
What the recipient experiences
A real bot-originated Telegram VoIP call sounds like a regular Telegram call from a contact named (in our case) @WardenPointBot. There's no "robocall" overlay or weird audio quality — it's the same VoIP stack Telegram users use for personal calls. The voice content is the alert message converted to speech via the Edge-TTS pipeline; pause / digit-press / hang-up all work the same way as a regular call.
People HATE robocalls. They do not hate VoIP calls from a bot they signed up to. This matters a lot for retention: an on-call engineer who's been woken up 47 times this quarter by a friendly-sounding bot is annoyed at the system but not at us. Someone woken up by a Twilio call with a synthetic monotone voice is annoyed at us.
How we wire it
Telegram bot → MadelineProto (TDLib wrapper) → libtgvoip stream → Edge-TTS produces the voice payload → bot initiates a VoIP call to the recipient. The user has to have started a chat with the bot once (so the bot has permission to call them); after that, all calls flow without per-call setup.
The escalation policy treats the VoIP attempt as "attempt with low cost, high signal" — it's the first thing tried because it's cheap AND loud. That's a rare combination.
Keep reading
Related posts

PHP FFI was the wrong tool: a child-process bridge for Telegram VoIP
How a GLib background thread corrupted the Zend heap in production, why we moved ntgcalls into a child process speaking JSON over pipes, and the two deadlocks plus one 6x latency win on the way to one-second Telegram VoIP calls.

Migrating from PagerDuty: a step-by-step playbook
A practical sequence we walk customers through to leave PagerDuty without dropping a single alert — services, schedules, escalation policies, integrations and the dual-fire sanity window.

On-call rotation design — what we learned building one
Six rules we landed on after running on-call for a 4-person ops team for two years — primary/secondary handoff, weekend rotation length, the «follow the sun» trap, and how to compensate for it.