louislam/uptime-kuma

Notification lost if service is temporarily unavailable

Open

#6046 opened on Aug 8, 2025

View on GitHub
 (4 comments) (0 reactions) (0 assignees)JavaScript (86,760 stars) (7,844 forks)batch import
A:notificationsfeature-requesthelp wanted

Description

📑 I have found these related issues/pull requests

Searched but didn't find any related issue/PR

🛡️ 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

Contributor guide

Tech stack
javascriptnodejssqlite
Domain
backendinfrastructure
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
half day
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Node.js knowledgeAsync/await patternsNotification system overview
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
70
Research direction
Investigate the notification sending logic in Uptime Kuma, likely in 'server/notification.js' or similar files. Identify where the failure occurs when the notification server is unreachable. Implement a retry mechanism with exponential backoff or a notification queue. Consider adding a persistent queue (e.g., using SQLite) to store failed notifications and retry them periodically. Check for any existing event loops or schedulers that could trigger retries. Ensure no duplicate notifications are sent after the outage resolves.