starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Distinguish notifications coming from different uptime-kuma instance #3664

New issue

Closed

opened 2026-02-28 03:37:10 -05:00 by deekerman · 4 comments

deekerman commented

2026-02-28 03:37:10 -05:00

Owner

Originally created by @arthef on GitHub (Oct 14, 2024).

⚠️ Please verify that this question has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

📝 Describe your problem

Hi,

We have a few instances of uptime-kuma running and sending us notifications. If there is a problem with one instance and it starts sending us lots of notifications it is hard to tell which one this is.
Is there any way we can distinguish from which instance these notifications are coming? Or maybe there is some configuration option to add some kind of identification tag to notifications for each instance?

📝 Error Message(s) or Log

No response

🐻 Uptime-Kuma Version

1.23.15

💻 Operating System and Arch

Docker on Linux

🌐 Browser

Any

🖥️ Deployment Environment

Runtime: Docker
Database: sqlite
Filesystem used to store the database on:
number of monitors: 50

Originally created by @arthef on GitHub (Oct 14, 2024). ### ⚠️ Please verify that this question has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### 📝 Describe your problem Hi, We have a few instances of uptime-kuma running and sending us notifications. If there is a problem with one instance and it starts sending us lots of notifications it is hard to tell which one this is. Is there any way we can distinguish from which instance these notifications are coming? Or maybe there is some configuration option to add some kind of identification tag to notifications for each instance? ### 📝 Error Message(s) or Log _No response_ ### 🐻 Uptime-Kuma Version 1.23.15 ### 💻 Operating System and Arch Docker on Linux ### 🌐 Browser Any ### 🖥️ Deployment Environment - Runtime: Docker - Database: sqlite - Filesystem used to store the database on: - number of monitors: 50

deekerman

2026-02-28 03:37:10 -05:00

closed this issue
added the
help
label

deekerman commented

2026-02-28 03:37:15 -05:00

Author

Owner

@apio-sys commented on GitHub (Oct 15, 2024):

I personally have 2 UK instances running in different networks but some hosts are monitored by both. The way I easily recognize which Kuma sends me an alert is simply from the "from address" of that Kuma server in the alert notification (by email). Is that somewhat answering your question?

@apio-sys commented on GitHub (Oct 15, 2024): I personally have 2 UK instances running in different networks but some hosts are monitored by both. The way I easily recognize which Kuma sends me an alert is simply from the "from address" of that Kuma server in the alert notification (by email). Is that somewhat answering your question?

deekerman commented

2026-02-28 03:37:15 -05:00

Author

Owner

@arthef commented on GitHub (Oct 19, 2024):

We send notifications through text messages to mobile numbers of our team. I guess, we could use a different number for each instance but that would be an overkill. A small indicator in the notification message would be the best option.

@arthef commented on GitHub (Oct 19, 2024): We send notifications through text messages to mobile numbers of our team. I guess, we could use a different number for each instance but that would be an overkill. A small indicator in the notification message would be the best option.

deekerman commented

2026-02-28 03:37:15 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Oct 19, 2024):

Currently, adding Tags as asked is neither existing, nor planned.

At the core, what you want is

#646

This has been implmented for smtp and webhook, but parts need to be generalised and then started to rollout over the notification-providers.

Depending on your concrete situation, there might be other operational things that you can do. Using a different number for a different thing (otherwise they would be one instance, right?) or naming the monitors better, f.ex. Compute Cloud EU-West 2 instead of Compute Cloud are solutions.

@CommanderStorm commented on GitHub (Oct 19, 2024): Currently, adding Tags as asked is neither existing, nor planned. At the core, what you want is - #646 This has been implmented for `smtp` and `webhook`, but parts need to be generalised and then started to rollout over the notification-providers. Depending on your concrete situation, there might be other operational things that you can do. Using a different number for a different thing (otherwise they would be one instance, right?) or naming the monitors better, f.ex. `Compute Cloud EU-West 2` instead of `Compute Cloud` are solutions.

deekerman commented

2026-02-28 03:37:15 -05:00

Author

Owner

@arthef commented on GitHub (Oct 19, 2024):

Thank you for your response and explanation. This gave me some ideas on how to solve the problem.

The thing is, we have 3 instances of uptime-kuma in different locations, all of them monitor our 50 or so services. For redundancy. And they also monitor each other. Maybe this is an overkill but our services are super critical for our business, hence the redundancy. So, they are doing pretty much the same thing.

It just happened a few times, that we had network issues at some location and the uptime-kuma went crazy sending us notifications about service down and up to our mobile phones. It wasn't easy to find out which instance is sending these notifications.

However, as I understand your suggestion, we could add some kind of suffix to the monitored target name, different for each instance of the uptime-kuma. This way we could identify where this notification comes from.

@arthef commented on GitHub (Oct 19, 2024): Thank you for your response and explanation. This gave me some ideas on how to solve the problem. The thing is, we have 3 instances of uptime-kuma in different locations, all of them monitor our 50 or so services. For redundancy. And they also monitor each other. Maybe this is an overkill but our services are super critical for our business, hence the redundancy. So, they are doing pretty much the same thing. It just happened a few times, that we had network issues at some location and the uptime-kuma went crazy sending us notifications about service down and up to our mobile phones. It wasn't easy to find out which instance is sending these notifications. However, as I understand your suggestion, we could add some kind of suffix to the monitored target name, different for each instance of the uptime-kuma. This way we could identify where this notification comes from.