starred/uptime-kuma

Fork 0

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

Hierarchical/Master Status Pages - Ability to Link Multiple Status Pages #4236

New issue

Open

opened 2026-02-28 03:55:42 -05:00 by deekerman · 7 comments

deekerman commented

2026-02-28 03:55:42 -05:00

Owner

Originally created by @eangulus on GitHub (Aug 2, 2025).

I searched for related issues and found:

#5599 discusses linking multiple Uptime Kuma installations but focuses on multi-site deployment rather than hierarchical organization
No existing issues specifically request the ability to create master status pages that aggregate multiple status pages
This request differs by focusing on creating a hierarchical view within a single Uptime Kuma instance where one status page can show the overall health of other status pages and link to them.

🏷️ Feature Request Type

Status-page

🔖 Feature description

Add the ability to create hierarchical or "master" status pages that can display the overall health status of other status pages and provide navigation links to them.

Currently, each status page operates independently. This feature would allow administrators to create organizational hierarchy in their status pages, enabling a top-level overview that shows the health of different service categories.

✔️ Solution

Implement one of these approaches:

Option 1: External Status Page Monitor Type

Add a new monitor type called "External Status Page" or "Child Status Page"
This monitor type checks the overall health of another Uptime Kuma status page (internal or external)
Shows as "All Services Operational" / "Some Services Down" / "Major Outage" based on the target status page's overall health
Clicking the monitor name navigates to the linked status page

Option 2: Status Page Linking Feature

Add ability to "embed" or "link" existing status pages as sections within a master status page
Master status page shows: "Internal Services: ✅", "Third Party Services: ⚠️", "Websites: ✅"
Each section shows overall health and links to the detailed status page when clicked

❓ Alternatives

Current Workarounds:

Multiple browser bookmarks to different status pages
Manual checking of each status page individually
Using external tools to aggregate status via API (requires custom development)

Other Solutions Considered:

Using groups within a single status page (but this doesn't provide the organizational separation needed)
Multiple Uptime Kuma instances (adds complexity and maintenance overhead)

📝 Additional Context

Use Case Example: A system administrator manages:

Internal infrastructure status page (databases, servers, internal APIs)
Third-party services status page (external APIs, CDNs, payment processors)
Public-facing services status page (websites, customer portals)

Instead of checking three separate status pages, they want a master dashboard showing:

Master Status Overview
├── Internal Services: ✅ All Operational
├── Third Party Services: ⚠️ 1 Service Degraded
└── Public Services: ✅ All Operational

Clicking "Third Party Services" would navigate to that specific status page to see which service is degraded.

This would be particularly valuable for:

Organizations with multiple service categories
MSPs managing multiple client environments
Teams that need both high-level overview and detailed drill-down capability
Situations where different stakeholders need access to different status page subsets

Originally created by @eangulus on GitHub (Aug 2, 2025). ### 📑 I have found these related issues/pull requests I searched for related issues and found: - #5599 discusses linking multiple Uptime Kuma installations but focuses on multi-site deployment rather than hierarchical organization No existing issues specifically request the ability to create master status pages that aggregate multiple status pages - This request differs by focusing on creating a hierarchical view within a single Uptime Kuma instance where one status page can show the overall health of other status pages and link to them. ### 🏷️ Feature Request Type Status-page ### 🔖 Feature description Add the ability to create hierarchical or "master" status pages that can display the overall health status of other status pages and provide navigation links to them. Currently, each status page operates independently. This feature would allow administrators to create organizational hierarchy in their status pages, enabling a top-level overview that shows the health of different service categories. ### ✔️ Solution Implement one of these approaches: **Option 1: External Status Page Monitor Type** - Add a new monitor type called "External Status Page" or "Child Status Page" - This monitor type checks the overall health of another Uptime Kuma status page (internal or external) - Shows as "All Services Operational" / "Some Services Down" / "Major Outage" based on the target status page's overall health - Clicking the monitor name navigates to the linked status page **Option 2: Status Page Linking Feature** - Add ability to "embed" or "link" existing status pages as sections within a master status page - Master status page shows: "Internal Services: ✅", "Third Party Services: ⚠️", "Websites: ✅" - Each section shows overall health and links to the detailed status page when clicked ### ❓ Alternatives **Current Workarounds:** - Multiple browser bookmarks to different status pages - Manual checking of each status page individually - Using external tools to aggregate status via API (requires custom development) **Other Solutions Considered:** - Using groups within a single status page (but this doesn't provide the organizational separation needed) - Multiple Uptime Kuma instances (adds complexity and maintenance overhead) ### 📝 Additional Context **Use Case Example:** A system administrator manages: - Internal infrastructure status page (databases, servers, internal APIs) - Third-party services status page (external APIs, CDNs, payment processors) - Public-facing services status page (websites, customer portals) Instead of checking three separate status pages, they want a master dashboard showing: Master Status Overview ├── Internal Services: ✅ All Operational ├── Third Party Services: ⚠️ 1 Service Degraded └── Public Services: ✅ All Operational Clicking "Third Party Services" would navigate to that specific status page to see which service is degraded. This would be particularly valuable for: - Organizations with multiple service categories - MSPs managing multiple client environments - Teams that need both high-level overview and detailed drill-down capability - Situations where different stakeholders need access to different status page subsets

deekerman added the

feature-request

A:status-page

labels

2026-02-28 03:55:42 -05:00

deekerman commented

2026-02-28 03:55:44 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 2, 2025):

I think sysadmins checking status pages is not something that is a good use case.

At least what I learned from the SREs at Google in uni they are far go buisy for this and alerting (i.e. notifications) is more efficient.

@CommanderStorm commented on GitHub (Aug 2, 2025): I think sysadmins checking status pages is not something that is a good use case. At least what I learned from the SREs at Google in uni they are far go buisy for this and alerting (i.e. notifications) is more efficient.

deekerman commented

2026-02-28 03:55:44 -05:00

Author

Owner

@eangulus commented on GitHub (Aug 2, 2025):

I don't understand.

I know when my shit us down sometimes before an alert, I never said I wanted this instead of alerts either.

And having this would allow me to make usable status page setup for my staff so I don't get 100 calls on 30min telling me about an issue I already know exists and am trying to work on it.

@eangulus commented on GitHub (Aug 2, 2025): I don't understand. I know when my shit us down sometimes before an alert, I never said I wanted this instead of alerts either. And having this would allow me to make usable status page setup for my staff so I don't get 100 calls on 30min telling me about an issue I already know exists and am trying to work on it.

deekerman commented

2026-02-28 03:55:44 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 2, 2025):

If you know that there is planned downtime, you can enable an maintenance period

@CommanderStorm commented on GitHub (Aug 2, 2025): If you know that there is planned downtime, you can enable an maintenance period

deekerman commented

2026-02-28 03:55:44 -05:00

Author

Owner

@eangulus commented on GitHub (Aug 2, 2025):

And if it's not planned?

Don't worry about it. Close this off.

I'm starting to understand the attitude here.

Sorry waste your time, and sorry I wasted mine.

@eangulus commented on GitHub (Aug 2, 2025): And if it's not planned? Don't worry about it. Close this off. I'm starting to understand the attitude here. Sorry waste your time, and sorry I wasted mine.

deekerman commented

2026-02-28 03:55:44 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 2, 2025):

We won't add hirarchical monitoring sites grouping inheritance (i.e. one UK instance monitoring another).
That part is out of scope.

What I would be open to is making the links for groups (I think this is the part you want) configurable:

https://github.com/louislam/uptime-kuma/issues/4072

I think regular monitors have their url configurable.

Regarding your actual FR

If the implementation of such master status pages is clean, I would consider the implementation nevertheless. Really depends on if such an implementaion increases or decreases entropy.
Feel free to do exploratory work what needs to be changed how.

Our contribution guide is here https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md

@CommanderStorm commented on GitHub (Aug 2, 2025): We won't add hirarchical monitoring sites grouping inheritance (i.e. one UK instance monitoring another). That part is out of scope. What I would be open to is making the links for groups (I think this is the part you want) configurable: - https://github.com/louislam/uptime-kuma/issues/4072 I think regular monitors have their url configurable. Regarding your actual FR If the implementation of such master status pages is clean, I would consider the implementation nevertheless. Really depends on if such an implementaion increases or decreases entropy. Feel free to do exploratory work what needs to be changed how. Our contribution guide is here https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md

deekerman commented

2026-02-28 03:55:44 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 2, 2025):

is this planned

This is OSS, not a company, so really depends if an volunteer wants to do that work. I won't implement it as this is not something I need, but I can review it if it is a reasonable implementation.

@CommanderStorm commented on GitHub (Aug 2, 2025): > is this planned This is OSS, not a company, so really depends if an volunteer wants to do that work. I won't implement it as this is not something I need, but I can review it if it is a reasonable implementation.

deekerman commented

2026-02-28 03:55:44 -05:00

Author

Owner

@eangulus commented on GitHub (Aug 2, 2025):

I wasn't asking for one instance to monitor another.

I was asking for the ability to add Status Pages, in the same instance, to another Status page.

For example. I could build out a Status Page of 3rd Party Services, another for Databases, another for Docker containers.

But then have 1 Status Page, where I can put in each of the other status pages, in the same way as we add Monitors and Groups, where it just shows the Status of the Page itself, and a link to that dedicated page.

I then would have a page showing 3rd party, databases, Docker containers. Could have a 3-item page, and know if any of these are up or down, and if, say, containers shows down, I can click on it to go to the containers status page, and see which one.

I don't understand why people are thinking this is such an advanced specific use case here.

If it's such a problem, I'll quit, and just build my own primary status page using APIs. Just thought it might be a feature everyone could do with. Another one I would like but that has already been mentioned somewhere is the ability to put a monitor in multiple groups.

This way I could have a group for each website/domain that includes web server, domain, database and anything else needed for the site to operate. But I may have the same database for multiple sites. Rather than having to duplicate the database monitor, it would be convenient to add my one database monitor to several groups.

@eangulus commented on GitHub (Aug 2, 2025): I wasn't asking for one instance to monitor another. I was asking for the ability to add Status Pages, in the same instance, to another Status page. For example. I could build out a Status Page of 3rd Party Services, another for Databases, another for Docker containers. But then have 1 Status Page, where I can put in each of the other status pages, in the same way as we add Monitors and Groups, where it just shows the Status of the Page itself, and a link to that dedicated page. I then would have a page showing 3rd party, databases, Docker containers. Could have a 3-item page, and know if any of these are up or down, and if, say, containers shows down, I can click on it to go to the containers status page, and see which one. I don't understand why people are thinking this is such an advanced specific use case here. If it's such a problem, I'll quit, and just build my own primary status page using APIs. Just thought it might be a feature everyone could do with. Another one I would like but that has already been mentioned somewhere is the ability to put a monitor in multiple groups. This way I could have a group for each website/domain that includes web server, domain, database and anything else needed for the site to operate. But I may have the same database for multiple sites. Rather than having to duplicate the database monitor, it would be convenient to add my one database monitor to several groups.