starred/uptime-kuma

Fork 0

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

Add a monitor type for upstream status pages #4308

New issue

Closed

opened 2026-02-28 03:57:55 -05:00 by deekerman · 6 comments

deekerman commented

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

Owner

Originally created by @thislooksfun on GitHub (Sep 25, 2025).

I think https://github.com/louislam/uptime-kuma/issues/6028 is a strict subset of this feature request -- specifically for adding an "upstream" status page where the host is Uptime Kuma.

🏷️ Feature Request Type

New monitor

🔖 Feature description

In the modern world it is very common for services to rely on upstream services. It would be really nice if Uptime Kuma had a way cleanly add the status of upstream services to a status page. For example, if you rely on Twilio for sending text messages you could link the Twilio Status page, or if you take payments you could have an entry for Stripe.

✔️ Solution

I would like a way to add the overall status of an upstream status page to my Uptime Kuma status page, without needing to build a bespoke HTTP monitor every time. Since most places I've encountered use a relatively small set of status page tooling (Atlassian Statuspage and Instatus are by far the most common I've personally seen), having a first-class integration for those would make tracking the status of third-party services very user-friendly.

Ideally this would be as simple as:

Make a new monitor
Set the type to "status page"
Enter a URL
Select the underlying technology (Atlassian Statuspage / Instatus / Uptime Kuma / etc). Ideally this will be able to detect the platform automatically, but the user should be able to override it if it gets it wrong somehow

❓ Alternatives

We could build custom HTTP monitors for each upstream status page we want to track, but that gets complicated quickly, especially since I would ideally like to see more fine-grained status (e.g. is the upstream fully down? or is it just degraded?).

📝 Additional Context

No response

Originally created by @thislooksfun on GitHub (Sep 25, 2025). ### 📑 I have found these related issues/pull requests I think https://github.com/louislam/uptime-kuma/issues/6028 is a strict subset of this feature request -- specifically for adding an "upstream" status page where the host is Uptime Kuma. ### 🏷️ Feature Request Type New monitor ### 🔖 Feature description In the modern world it is very common for services to rely on upstream services. It would be really nice if Uptime Kuma had a way cleanly add the status of upstream services to a status page. For example, if you rely on Twilio for sending text messages you could link the [Twilio Status page](https://status.twilio.com), or if you take payments you could have an entry for [Stripe](https://status.stripe.com). ### ✔️ Solution I would like a way to add the overall status of an upstream status page to my Uptime Kuma status page, without needing to build a bespoke HTTP monitor every time. Since most places I've encountered use a relatively small set of status page tooling (Atlassian Statuspage and Instatus are by far the most common I've personally seen), having a first-class integration for those would make tracking the status of third-party services very user-friendly. Ideally this would be as simple as: 1. Make a new monitor 2. Set the type to "status page" 3. Enter a URL 4. Select the underlying technology (Atlassian Statuspage / Instatus / Uptime Kuma / etc). Ideally this will be able to detect the platform automatically, but the user should be able to override it if it gets it wrong somehow ### ❓ Alternatives We could build custom HTTP monitors for each upstream status page we want to track, but that gets complicated quickly, especially since I would ideally like to see more fine-grained status (e.g. is the upstream fully down? or is it just degraded?). ### 📝 Additional Context _No response_

deekerman

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

closed this issue
added the
feature-request
label

deekerman commented

2026-02-28 03:57:58 -05:00

Author

Owner

@maxmichels commented on GitHub (Oct 24, 2025):

@thislooksfun what would be your expectation in case there is some warning/issue reported? For example there are currently 6 incidents at Twilio:

But only some services are affected:

Should the Monitor then fail as soon as there is one incident reported? I think this is kind of impossible as you would need to define what exact service you are relying on.

E.g. SMS delivery to Europe is working fine, UK not. Is the monitor now failing besides for me everything would be working? Or for UK push notification is also working.

@maxmichels commented on GitHub (Oct 24, 2025): @thislooksfun what would be your expectation in case there is some warning/issue reported? For example there are currently 6 incidents at Twilio: <img width="3300" height="1796" alt="Image" src="https://github.com/user-attachments/assets/4ff454e1-bf69-46ab-bc3a-d7a6eb29c2cf" /> But only some services are affected: <img width="2334" height="1554" alt="Image" src="https://github.com/user-attachments/assets/7a67be37-b801-433f-9956-29c1f2b0e91b" /> Should the Monitor then fail as soon as there is one incident reported? I think this is kind of impossible as you would need to define what exact service you are relying on. E.g. SMS delivery to Europe is working fine, UK not. Is the monitor now failing besides for me everything would be working? Or for UK push notification is also working.

deekerman commented

2026-02-28 03:58:00 -05:00

Author

Owner

@thislooksfun commented on GitHub (Oct 27, 2025):

For me the MVP is "if any upstream monitor is down, then error, else ok". That will be sufficient for most non-Twilio use cases.

My ideal setup is more nuanced: I would like to be able to choose the set of items that the monitor is watching for (like when you subscribe to one of the status pages directly, you can choose which monitors to get alerts for). I would also like it to have an amber "degraded" status, with the logic of: "if any selected upstream monitor is erroring, then error; else if any selected monitor is degraded, then be degraded; else ok". But I do realize that both of those asks are more work.

@thislooksfun commented on GitHub (Oct 27, 2025): For me the MVP is "if any upstream monitor is down, then error, else ok". That will be sufficient for most non-Twilio use cases. My _ideal_ setup is more nuanced: I would like to be able to choose the set of items that the monitor is watching for (like when you subscribe to one of the status pages directly, you can choose which monitors to get alerts for). I would also like it to have an amber "degraded" status, with the logic of: "if any selected upstream monitor is erroring, then error; else if any selected monitor is degraded, then be degraded; else ok". But I do realize that both of those asks are more work.

deekerman commented

2026-02-28 03:58:00 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Oct 27, 2025):

Supporting all other status page apis that exist is not something that we can support.
There are too many different status page APIs out there.

We don't have the dev power to support this:

#6260

What you actually want is the following:

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

@CommanderStorm commented on GitHub (Oct 27, 2025): Supporting all other status page apis that exist is not something that we can support. There are too many different status page APIs out there. We don't have the dev power to support this: - #6260 What you actually want is the following: - https://github.com/louislam/uptime-kuma/issues/1089

deekerman commented

2026-02-28 03:58:00 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Oct 27, 2025):

A more copy pastable / templatable monitior addition would likely also be possible.
Not sure.
There are a few related issues for this

@CommanderStorm commented on GitHub (Oct 27, 2025): A more copy pastable / templatable monitior addition would likely also be possible. Not sure. There are a few related issues for this

deekerman commented

2026-02-28 03:58:00 -05:00

Author

Owner

@thislooksfun commented on GitHub (Oct 27, 2025):

What you actually want is the following:

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

No, I don't want that. That might help if all the monitor pages were in the same Kuma instance, but at that point I can use groups to solve the issue as well.

Supporting all other status page apis that exist is not something that we can support.
There are too many different status page APIs out there.

We don't have the dev power to support this

Perfectly reasonable, and honestly the answer I expected. Figured I'd ask though!

@thislooksfun commented on GitHub (Oct 27, 2025): > What you actually want is the following: > - https://github.com/louislam/uptime-kuma/issues/1089 No, I don't want that. That might help if all the monitor pages were in the same Kuma instance, but at that point I can use groups to solve the issue as well. > Supporting all other status page apis that exist is not something that we can support. > There are too many different status page APIs out there. > > We don't have the dev power to support this Perfectly reasonable, and honestly the answer I expected. Figured I'd ask though!

deekerman commented

2026-02-28 03:58:00 -05:00

Author

Owner

@jo-nike commented on GitHub (Dec 14, 2025):

@thislooksfun if I understood correctly, for Atlassian status page you could just request the JSON version (https://status.twilio.com/api/v2/summary.json for example) of the status page and parse the JSON with the already existing JSON query parser, you could easily choose what you want/dont want too and not take everything out of twilio page.

@jo-nike commented on GitHub (Dec 14, 2025): @thislooksfun if I understood correctly, for Atlassian status page you could just request the JSON version (https://status.twilio.com/api/v2/summary.json for example) of the status page and parse the JSON with the already existing JSON query parser, you could easily choose what you want/dont want too and not take everything out of twilio page.