Notification lost if service is temporarily unavailable #4251

New issue

Open

opened 2026-02-28 03:56:05 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-28 03:56:05 -05:00

Owner

Originally created by @m4rc0d1 on GitHub (Aug 8, 2025).

Searched but didn't find any related issue/PR

🛡️ Security Policy

I have read and agree to Uptime Kuma's Security Policy.

📝 Description

If the notification server is temporarily unreachable/unavailable at the moment of the down/up event, no retries are attempted to send the notification.
I have a dual internet connection with a primary and a backup link. If the primary link fails there is a small delay (seconds) before the primary router switches to the backup link and during this short period of time the Telegram server is inaccessible from Uptime Kuma. The down notification of the primary link is never received even if Telegram is reachable just few seconds later. I have not checked if this is just related to Telegram or a more general behavior also affecting other notification channels.

👟 Reproduction steps

disable internet connection (or just api.telegram.org) from Uptime Kuma
down any monitor configured with a Telegram notification
wait 5-10 seconds
re-enable internet/telegram connectivity
check that no down notification is sent

👀 Expected behavior

The down notification is retried and sent as soon as a connection with the notification service is available.

😓 Actual Behavior

No notification is sent

🐻 Uptime-Kuma Version

1.23.15

💻 Operating System and Arch

Debian GNU/Linux 12.8 (bookworm)

🌐 Browser

Firefox 141.0.3

🖥️ Deployment Environment

Runtime Environment:
- Docker: Docker version 27.3.1, build ce12230
- Docker Compose: Docker Compose version v2.29.7
Database:
- SQLite: Embedded
Database Storage:
- Filesystem:
  - Linux: Btrfs
- Storage Medium: NVMe + SSD (RAID1)
Uptime Kuma Setup:
- Number of monitors: 22

📝 Relevant log output

Originally created by @m4rc0d1 on GitHub (Aug 8, 2025). ### 📑 I have found these related issues/pull requests Searched but didn't find any related issue/PR ### 🛡️ Security Policy - [x] I have read and agree to Uptime Kuma's [Security Policy](https://github.com/louislam/uptime-kuma/security/policy). ### 📝 Description If the notification server is temporarily unreachable/unavailable at the moment of the down/up event, no retries are attempted to send the notification. I have a dual internet connection with a primary and a backup link. If the primary link fails there is a small delay (seconds) before the primary router switches to the backup link and during this short period of time the Telegram server is inaccessible from Uptime Kuma. The down notification of the primary link is never received even if Telegram is reachable just few seconds later. I have not checked if this is just related to Telegram or a more general behavior also affecting other notification channels. ### 👟 Reproduction steps 1. disable internet connection (or just api.telegram.org) from Uptime Kuma 2. down any monitor configured with a Telegram notification 3. wait 5-10 seconds 4. re-enable internet/telegram connectivity 5. check that no down notification is sent ### 👀 Expected behavior The down notification is retried and sent as soon as a connection with the notification service is available. ### 😓 Actual Behavior No notification is sent ### 🐻 Uptime-Kuma Version 1.23.15 ### 💻 Operating System and Arch Debian GNU/Linux 12.8 (bookworm) ### 🌐 Browser Firefox 141.0.3 ### 🖥️ Deployment Environment - **Runtime Environment**: - Docker: Docker version 27.3.1, build ce12230 - Docker Compose: Docker Compose version v2.29.7 - **Database**: - SQLite: Embedded - **Database Storage**: - **Filesystem**: - Linux: Btrfs - **Storage Medium**: NVMe + SSD (RAID1) - **Uptime Kuma Setup**: - Number of monitors: 22 ### 📝 Relevant log output ```bash session ```

deekerman added the

feature-request

A:notifications

help wanted

labels

2026-02-28 03:56:05 -05:00

deekerman commented

2026-02-28 03:56:09 -05:00

Author

Owner

@m4rc0d1 commented on GitHub (Aug 8, 2025):

It is not just related to Telegram. I've done some additional tests and at least also WebHooks have the same behavior so it seems a more general issue

@m4rc0d1 commented on GitHub (Aug 8, 2025): It is not just related to Telegram. I've done some additional tests and at least also WebHooks have the same behavior so it seems a more general issue