[GH-ISSUE #557] Bypass telegram rate limit using message grouping/queueing #403

New issue

Closed

opened 2026-02-25 23:42:20 +03:00 by kerem · 2 comments

kerem commented

2026-02-25 23:42:20 +03:00

Owner

Originally created by @ypapouin on GitHub (Aug 26, 2021).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/557

Apparently, there is 30 msg/sec limit for a telegram bot.
When services depends on each others you can quickly reach this limit and have an inconsistent feedback state in your messaging app.

Since the minimal check unit is the minute, my proposal is to group check states changes in one message per project that would be sent every 60s if any. It implies to keep a queue of any state changes.

The other way is to also keep a global telegram queue and slowly dequeue it with a rate of one message every 2 seconds.

Originally created by @ypapouin on GitHub (Aug 26, 2021). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/557 Apparently, there is 30 msg/sec limit for a telegram bot. When services depends on each others you can quickly reach this limit and have an inconsistent feedback state in your messaging app. Since the minimal check unit is the minute, my proposal is to group check states changes in one message per project that would be sent every 60s if any. It implies to keep a queue of any state changes. The other way is to also keep a global telegram queue and slowly dequeue it with a rate of one message every 2 seconds.

kerem

2026-02-25 23:42:20 +03:00

closed this issue
added the
feature
label

kerem commented

2026-02-25 23:42:20 +03:00

Author

Owner

@cuu508 commented on GitHub (Aug 27, 2021):

Can you share some details about your use case? When you are receiving 30+ Telegram messages per second, how are you going to notice a missing one?

There is also rate limiting for Telegram notifications on Healthchecks side – 6 messages per chat per minute.

my proposal is to group check states changes in one message per project that would be sent every 60s if any. It implies to keep a queue of any state changes.

One problem I see with this is Telegram notifications could get delayed up to a minute (when they need to be sent just after "the bus has left"). Another one is the additional complexity of maintaining a queue.

@cuu508 commented on GitHub (Aug 27, 2021): Can you share some details about your use case? When you are receiving 30+ Telegram messages per second, how are you going to notice a missing one? There is also rate limiting for Telegram notifications on Healthchecks side – [6 messages per chat per minute](https://github.com/healthchecks/healthchecks/blob/master/hc/api/models.py#L914). > my proposal is to group check states changes in one message per project that would be sent every 60s if any. It implies to keep a queue of any state changes. One problem I see with this is Telegram notifications could get delayed up to a minute (when they need to be sent just after "the bus has left"). Another one is the additional complexity of maintaining a queue.

kerem commented

2026-02-25 23:42:20 +03:00

Author

Owner

@cuu508 commented on GitHub (Dec 8, 2021):

I think the 6 messages per chat per minute rate limit is reasonable.

However, when, let's say 100 checks go down all at the same time, there is a risk the user will receive 6 notifications, and will not realize there are 94 more failures – the problem is bigger. To help with that, I updated the Telegram notification template to also list other checks currently down:

@cuu508 commented on GitHub (Dec 8, 2021): I think the 6 messages per chat per minute rate limit is reasonable. However, when, let's say 100 checks go down all at the same time, there is a risk the user will receive 6 notifications, and will not realize there are 94 more failures – the problem is bigger. To help with that, I updated the Telegram notification template to also list other checks currently down: ![image](https://user-images.githubusercontent.com/661859/145236552-259dabec-aa99-499c-b99c-c5b98b5f7aa7.png)