Bot type
Alerts that someone has to acknowledge, not another muted group
A Telegram dispatch bot pushes a job or alert to the right person, requires an acknowledgement, and escalates when none arrives within a set time. It replaces a group chat where everyone assumes someone else is handling it. It does not decide priority for you.
Notification and dispatch bots: price, timeline and limits
- Fixed price
- $3,400 USD
- Delivery
- 16 calendar days from kickoff
- Broadcast ceiling
- ~30 messages/second bot-wide, ~20/minute per group
- Cold outreach
- Not possible — the recipient must message the bot first
- Delivery proof
- Send confirmation only, no delivery or read receipt
- Blocked recipients
- Send fails with an explicit error
As of 2025-10-01, Telegram Bot API 13.4
The problem this solves
Operations teams almost always start with a group chat, and for a while it works. The failure arrives quietly: the group grows, the messages become constant, and people mute it. From that moment the channel that carries your urgent work is one that nobody reads promptly, and nobody has noticed because messages still appear to be delivered.
The specific defect is that a group message has no addressee and no state. It has been seen or not seen, and there is no difference between a job everyone assumes is handled and a job nobody has touched. The most expensive incidents in maintenance, field service and facilities are almost never caused by a missing alert. They are caused by an alert that everyone saw and each person assumed belonged to someone else.
What changes the outcome is addressing and acknowledgement. A job goes to a named person, that person has to tap to accept it, and if they do not within the window it escalates to the next. It sounds trivial and it changes behaviour immediately, because the ambiguity that made ignoring it comfortable is gone.
How the build runs
The event arrives from whatever system detects it
A monitoring alert, a ticket, a sensor threshold, a form submission. The bot does not detect anything itself — it is the delivery and accountability layer over systems that already know something happened.
webhookRouting picks a person, not a group
The current rota, the required skill and the zone decide who receives it. A message addressed to one person behaves completely differently from the same message in a channel of thirty, and that difference is the product.
chat-member-updatesThe recipient must accept or decline
Two buttons and a visible countdown. Declining is a legitimate answer that moves the job on immediately; the failure mode being designed out is silence, not refusal.
inline-keyboardNo acknowledgement escalates on a timer
Priority sets the window — two minutes for a critical alert, thirty for a routine job. Escalation goes to the next person in the chain and then to a supervisor, with each hop recorded.
broadcastAccepted work carries a state anyone can see
Accepted, on site, done, or blocked with a reason. A dispatcher sees the board without asking, which removes the second-order interruption of chasing people for updates.
inline-keyboardEverything is logged for the argument afterwards
Who was notified, at what time, who accepted, how long acceptance took. This matters most in the review after something went badly, when memory is unreliable and the record is not.
webhook
What Telegram will and will not let you do
A bot may send roughly 30 messages per second, and about 20 per minute into a single group.
Direct messages to individuals are the fast path; group posts are the slow one. A design that fans out through one group chat will throttle exactly when an incident makes it busy.
A bot cannot message a user who has not started a conversation with it.
Every person on the rota must open the bot once before they can be dispatched to. Onboarding is a real step and belongs in the rollout plan rather than being discovered at the first escalation.
Telegram provides no delivery receipt for a message, only a send confirmation.
You know the message left; you do not know it was seen. This is precisely why acknowledgement is a button rather than an assumption, and why escalation is time-based.
A user who blocks the bot causes sends to fail with an explicit error.
That error is treated as an operational fault and surfaced to a supervisor. A blocked on-call engineer is a rota problem, and discovering it during an incident is the wrong time.
Telegram notification behaviour is controlled by the user's own device settings.
You cannot force a critical alert past a phone in Do Not Disturb. Where a genuine wake-up is required, the escalation chain has to end in a channel Telegram does not control, such as a phone call.
When not to build this
- You need guaranteed wake-up for life-safety alerts. Telegram cannot override a silenced phone, and a pager or a call-out service is the correct tool.
- Your team is under five people in one room. Speaking is faster, and the acknowledgement discipline will feel like bureaucracy because it is.
- There is no rota and no agreement about who owns what. The bot will route work to a structure that does not exist, and expose that rather than fix it.
- Your alerts are already so noisy that people ignore them. Making them harder to ignore without reducing the noise produces resentment, then muting, then the original problem.
What it runs on
| Component | Version | Why |
|---|---|---|
| grammY | 1.45 | Bot framework, with per-user conversation state for acknowledgement. |
| Cloudflare Workers | current | Runtime, with cron triggers driving the escalation timers. |
| Cloudflare D1 | current | Rota, jobs, acknowledgement state and the audit trail. |
| Zod | 4.4 | Validation on inbound webhooks from monitoring and ticketing systems. |
| TypeScript | 5.9 | Strict mode. Escalation is a state machine and benefits accordingly. |
Questions people ask before committing
How is this different from a Telegram group with @mentions?
A mention is a request for attention with no state. This build tracks whether the specific person accepted, and acts on its own when they did not. The difference shows up on the night when the person who was mentioned was asleep.
What happens if nobody in the chain acknowledges?
It escalates to the end of the chain and then raises a distinct supervisor alert stating that the chain was exhausted. It never quietly gives up, because a dispatch system that silently drops work is more dangerous than no system.
Can escalation windows differ by priority?
Yes, and they should. A critical alert with a thirty-minute window is theatre, and a routine job with a two-minute window trains people to accept without reading. Windows are configured per priority level.
Does it handle shift handover?
Yes. The rota knows who is on call, and escalation follows it rather than a fixed list. Handover is the moment most manual dispatch systems fail, because the list in someone's head is a day out of date.
Can it pull jobs from our ticketing system?
Yes, by webhook where your system supports it and by polling where it does not. The ticketing system stays the source of truth for what the job is; the bot owns who was told and whether they responded.
What does the audit trail actually contain?
Every notification sent, to whom, at what timestamp, every acknowledgement or decline, every escalation hop, and the final state. It is exportable, because its main use is a review meeting rather than a dashboard.