Building
How to schedule messages from a Telegram bot
By the Botable team
Telegram does not schedule messages for bots — your bot does. Store the message with a send time, run a scheduled check, and send when it is due. The two hard parts are timezones and what to do about missed sends after downtime.
The short version
Scheduling from a Telegram bot is your own job: the Bot API sends when told, and there is no queue for future delivery. So the pattern is a row holding the message, the destination and a send time, plus a worker that wakes periodically, finds what is due, sends it and marks it done. Two problems account for nearly all scheduling bugs. The first is timezones — Telegram does not tell a bot where a user is, so "nine in the morning" is nine on the server unless you have explicitly asked for and stored an offset, and the answer changes twice a year in most of the world. The second is downtime: when the worker was asleep for an hour, the correct behaviour for a missed reminder differs from a missed digest. Deciding whether a late send fires, is skipped, or is coalesced has to be an explicit choice per message type.
Step by step
How does the scheduling actually work?
Store what to send, where, and when. A worker runs on an interval — every minute is usually enough — selects everything due, sends it, and marks it sent in the same transaction. That last detail is what stops a crash mid-batch from re-sending on the next tick.
How do you handle timezones?
Ask the user once and store it. Store the schedule in their local terms and resolve to an absolute time at send, so daylight-saving transitions keep a nine-o'clock reminder at nine. Storing a fixed UTC offset instead means every schedule silently shifts by an hour twice a year.
What happens after downtime?
Decide per message type. A morning digest that missed its window should usually be skipped rather than arriving at midnight; a payment reminder should probably still go. Without a rule, a two-hour outage ends with every queued message arriving at once, which is worse than the outage.
How do recurring schedules differ?
A one-off is deleted after sending; a recurring one is rescheduled. Compute the next occurrence from the intended time rather than the actual send time, or a schedule that fires slightly late drifts a little further every day until it is hours off.
What catches people out
- Storing a fixed UTC offset breaks every schedule at each daylight-saving change
- Marking sent outside the send transaction lets a crash duplicate the message
- Computing the next recurrence from actual send time causes cumulative drift
Questions
Can it use Telegram's own scheduled messages feature?
That feature belongs to user accounts in the app, not to the Bot API. A bot schedules by holding the message itself, which is more flexible anyway since it can be cancelled or rewritten before it fires.
How precise is the timing?
As precise as your check interval, so a minute-level worker sends within a minute of the target. That is far more precision than reminders and digests need; sub-second scheduling is not a thing worth building here.
Want a bot that does this?
Describe it in plain language and Botable writes the code, gives the bot its own database, deploys it and keeps it running. Everything on this page is handled for you — the token, the webhook, the storage, the hosting.
Keep reading
- Rate limitstelegram bot rate limits
- Storing datatelegram bot database
- Broadcastingtelegram bot broadcast