starred/uptime-kuma

Fork 0

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

Main and Sub / Push monitor status to another uptime kuma instance #988

New issue

Closed

opened 2026-02-28 02:06:22 -05:00 by deekerman · 9 comments

deekerman commented

2026-02-28 02:06:22 -05:00

Owner

Originally created by @DunklerPhoenix on GitHub (Apr 16, 2022).

⚠️ Please verify that this feature request has NOT been suggested before.

I checked and didn't find similar feature request

🏷️ Feature Request Type

New Monitor, Other

🔖 Feature description

Two instances of uptime kuma are running.
One on local network and the other on a server on the internet.
It would be great if the local uptime kuma instance can push the monitor status to the public instance.

✔️ Solution

This could be done in form of a special notification service I think.

❓ Alternatives

Or as a complete new system

📝 Additional Context

I don't want to publish an uptime kuma instance that has access to my smart home mqtt server (e.g.)
So it would be great if there is a Main and Sub system or a reporting system between multiple instances.

Originally created by @DunklerPhoenix on GitHub (Apr 16, 2022). ### ⚠️ Please verify that this feature request has NOT been suggested before. - [X] I checked and didn't find similar feature request ### 🏷️ Feature Request Type New Monitor, Other ### 🔖 Feature description Two instances of uptime kuma are running. One on local network and the other on a server on the internet. It would be great if the local uptime kuma instance can push the monitor status to the public instance. ### ✔️ Solution This could be done in form of a special notification service I think. ### ❓ Alternatives Or as a complete new system ### 📝 Additional Context I don't want to publish an uptime kuma instance that has access to my smart home mqtt server (e.g.) So it would be great if there is a Main and Sub system or a reporting system between multiple instances.

deekerman

2026-02-28 02:06:22 -05:00

closed this issue
added the
feature-request

A:monitor
labels

deekerman commented

2026-02-28 02:06:26 -05:00

Author

Owner

@Computroniks commented on GitHub (Apr 17, 2022):

So you have 2 instances. One of them is publicly accessible. The private one monitors some services and you want to send this data to the public one. Am I along the right lines here?

@Computroniks commented on GitHub (Apr 17, 2022): So you have 2 instances. One of them is publicly accessible. The private one monitors some services and you want to send this data to the public one. Am I along the right lines here?

deekerman commented

2026-02-28 02:06:26 -05:00

Author

Owner

@DunklerPhoenix commented on GitHub (Apr 17, 2022):

Exactly.

@DunklerPhoenix commented on GitHub (Apr 17, 2022): Exactly.

deekerman commented

2026-02-28 02:06:26 -05:00

Author

Owner

@Computroniks commented on GitHub (Apr 17, 2022):

Is there any particular reason why not to make the internal server publicly accessible? It is possible to configure which monitors appear on the public status page and any that you don't want to make accessible are behind the login screen. It doesn't really make sense to me why you would have two separate instances like this. Perhaps I am missing something here.

@Computroniks commented on GitHub (Apr 17, 2022): Is there any particular reason why not to make the internal server publicly accessible? It is possible to configure which monitors appear on the public status page and any that you don't want to make accessible are behind the login screen. It doesn't really make sense to me why you would have two separate instances like this. Perhaps I am missing something here.

deekerman commented

2026-02-28 02:06:26 -05:00

Author

Owner

@DunklerPhoenix commented on GitHub (Apr 17, 2022):

The main idea is that my smart home is nearly completely offline. So I don't want that a tool shows itself tonthe outside. If a public instance get the informations pushed, then i think it's more difficult to understand for an attacker where it comes from

Yeah I'm a bit paranoid, but this scenario would also work for other networktypes i think ¯_(ツ)_/¯

@DunklerPhoenix commented on GitHub (Apr 17, 2022): The main idea is that my smart home is nearly completely offline. So I don't want that a tool shows itself tonthe outside. If a public instance get the informations pushed, then i think it's more difficult to understand for an attacker where it comes from Yeah I'm a bit paranoid, but this scenario would also work for other networktypes i think ¯\_(ツ)_/¯

deekerman commented

2026-02-28 02:06:26 -05:00

Author

Owner

@DunklerPhoenix commented on GitHub (Apr 17, 2022):

In my very limited understanding of this topic i think it would be a good solution to create an notification service as counterpart to the push monitor.

@DunklerPhoenix commented on GitHub (Apr 17, 2022): In my very limited understanding of this topic i think it would be a good solution to create an notification service as counterpart to the push monitor.

deekerman commented

2026-02-28 02:06:26 -05:00

Author

Owner

@Computroniks commented on GitHub (Apr 17, 2022):

I see where your coming from with this but it does seem a bit niche. There could possibly be a use for pushing to different types of monitors in an effort to integrate with existing infrastructure but we already have the Prometheus metrics page for that. Perhaps it might be worth looking into site to site VPNs or SSH tunnelling. Of course, this is just my opinion and I would be interested in seeing what others think.

@Computroniks commented on GitHub (Apr 17, 2022): I see where your coming from with this but it does seem a bit niche. There could possibly be a use for pushing to different types of monitors in an effort to integrate with existing infrastructure but we already have the Prometheus metrics page for that. Perhaps it might be worth looking into site to site VPNs or SSH tunnelling. Of course, this is just my opinion and I would be interested in seeing what others think.

deekerman commented

2026-02-28 02:06:26 -05:00

Author

Owner

@odyodyodys commented on GitHub (Aug 18, 2022):

Being able to have one public and several private would be amazing.
The idea is that the public displays specific statuses from the private(s).

@odyodyodys commented on GitHub (Aug 18, 2022): Being able to have one public and several private would be amazing. The idea is that the public displays specific statuses from the private(s).

deekerman commented

2026-02-28 02:06:26 -05:00

Author

Owner

@DunklerPhoenix commented on GitHub (Sep 26, 2022):

Another good reason for this feature is the docker monitor.
I don't need to open the docker service to the public and can run a local instance of uptime kuma on the docker host. This instance can then push its container monitors directly to the external public instance and docker is still safe

@DunklerPhoenix commented on GitHub (Sep 26, 2022): Another good reason for this feature is the docker monitor. I don't need to open the docker service to the public and can run a local instance of uptime kuma on the docker host. This instance can then push its container monitors directly to the external public instance and docker is still safe

deekerman commented

2026-02-28 02:06:26 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 5, 2023):

@DunklerPhoenix
We are consolidating duplicate issues a bit to make issue management easier.
I think, we should track this issue in #84 as there is no functional difference (maybe just small naming differences, but nothing that would require a different issue imo)
⇒ I am going to close this as a duplicate.

@CommanderStorm commented on GitHub (Dec 5, 2023): @DunklerPhoenix We are consolidating duplicate issues a bit to make issue management easier. I think, we should track this issue in #84 as there is no functional difference (maybe just small naming differences, but nothing that would require a different issue imo) ⇒ I am going to close this as a duplicate.