Notifications not sent when UK database is down

[jcjveraa]

📑 I have found these related issues/pull requests

Somewhat related as a topic to #6046

🛡️ Security Policy

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

📝 Description

Tested on external Mariadb, perhaps the same issue on others.
When the uptime kuma database (it's own database) is not available, UK stops functioning completely. It does not send a notification to inform UK itself is having issues.

👟 Reproduction steps

1. Run UK with an external MariaDB database
2. Take down the database.
3. Verify UK became unresponsive, and no notifications are triggered.

👀 Expected behavior

UK will send a notification to all notification channels that UK itself is having issues/is down.

😓 Actual Behavior

No notifications were sent

🐻 Uptime-Kuma Version

2.0.2

💻 Operating System and Arch

Debian Trixie (13.2), x86_64
Kernel Debian 6.12.57-1 (2025-11-05) x86_64

🌐 Browser

not relevant

🖥️ Deployment Environment

• Runtime Environment:
  • Docker: Version 26.1.5+dfsg1, build a72d7cd (default Debian Trixie package)
  • Docker Compose: Version 2.26.1-4 (default Debian Trixie package)
  • Portainer (BE/CE): N/A
  • MariaDB: Version 11.8.3-MariaDB (default Debian Trixie package)
  • Node.js: Version 20.19.5 (as provided by 'your' docker image)
  • Kubernetes (K3S/K8S): N/A
• Database:
  • MariaDB: External
• Database Storage:
  • Filesystem:
    • Linux: ext4
  • Storage Medium: NVMe
• Uptime Kuma Setup:
  • Number of monitors: 4
  • Nextcloud Talk notifications

📝 Relevant log output

redacted my server IP to 192.168.x.x

2025-12-15T19:24:19+01:00 [MONITOR] ERROR: Please report to https://github.com/louislam/uptime-kuma/issues
2025-12-15T19:24:19+01:00 [MONITOR] INFO: Try to restart the monitor
Trace: Error: connect EHOSTUNREACH 192.168.x.x:3306
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1611:16) {
  errno: -113,
  code: 'EHOSTUNREACH',
  syscall: 'connect',
  address: '192.168.x.x',
  port: 3306,
  fatal: true
}
    at Timeout.safeBeat [as _onTimeout] (/app/server/model/monitor.js:1021:25)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
2025-12-15T19:25:24+01:00 [MONITOR] ERROR: Please report to https://github.com/louislam/uptime-kuma/issues
2025-12-15T19:25:24+01:00 [MONITOR] INFO: Try to restart the monitor
Trace: Error: connect EHOSTUNREACH 192.168.x.x:3306
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1611:16) {
  errno: -113,
  code: 'EHOSTUNREACH',
  syscall: 'connect',
  address: '192.168.x.x',
  port: 3306,
  fatal: true
}
    at process.unexpectedErrorHandler (/app/server/server.js:1893:13)
    at process.emit (node:events:524:28)
    at emitUnhandledRejection (node:internal/process/promises:250:13)
    at throwUnhandledRejectionsMode (node:internal/process/promises:385:19)
    at processPromiseRejections (node:internal/process/promises:470:17)
    at process.processTicksAndRejections (node:internal/process/task_queues:96:32)
If you keep encountering errors, please report to https://github.com/louislam/uptime-kuma/issues
Trace: Error: connect EHOSTUNREACH 192.168.x.x:3306
    at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1611:16) {
  errno: -113,
  code: 'EHOSTUNREACH',
  syscall: 'connect',
  address: '192.168.x.x',
  port: 3306,
  fatal: true
}
    at Timeout.safeBeat [as _onTimeout] (/app/server/model/monitor.js:1021:25)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

[jcjveraa]

Meant to have this here as a Draft Issue, but that's not a n option - will complete with full environment details within the hour. done

[CommanderStorm]

That would make sense indeed.

[jcjveraa]

The solution is simple but perhaps implementation wise tricky, I haven’t looked at the source code yet, but if the auth tokens/urls/ etc for sending the notification (I’ll just call them “notification config”) are in the db this might pose a challenge. A solution could then be to cache all notification config in memory - it should not be a massive amount of data, a few kB per channel at most.

Otherwise it might make sense to add this as an (invisible?) regular “monitor”, with the special property that anytime a notification channel is added, that channel gets added to this monitor as well. The logic being that any channel that wants to get notified of some monitored app being down, probably also wants a notification if the monitor itself is down.