starred/uptime-kuma

Fork 0

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

Warning Status Code for HTTP(s) Monitors #3393

New issue

Open

opened 2026-02-28 03:27:53 -05:00 by deekerman · 4 comments

deekerman commented

2026-02-28 03:27:53 -05:00

Owner

Originally created by @casperdcl on GitHub (Jun 6, 2024).

#123 added an Accepted Status Code field (to mark services as "Up")
#819 discusses "Up but at risk" services

🏷️ Feature Request Type

Change to existing monitor

🔖 Feature description

It would be great to have a Degraded Status Code field too (to mark services as "Pending"/"Maintenance"/"Slow" rather than "Down")

✔️ Solution

Add a Degraded Status Code field to HTTP(s) monitors

Originally created by @casperdcl on GitHub (Jun 6, 2024). ### 📑 I have found these related issues/pull requests - #123 added an `Accepted Status Code` field (to mark services as "Up") - #819 discusses "Up but at risk" services ### 🏷️ Feature Request Type Change to existing monitor ### 🔖 Feature description It would be great to have a `Degraded Status Code` field too (to mark services as "Pending"/"Maintenance"/"Slow" rather than "Down") ### ✔️ Solution Add a `Degraded Status Code` field to `HTTP(s)` monitors

deekerman added the

feature-request

question

A:monitor

type:enhance-existing

labels

2026-02-28 03:27:53 -05:00

deekerman commented

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

Author

Owner

@CommanderStorm commented on GitHub (Jun 7, 2024):

Think that this is an implementation specific thing => should be handled in the respecitive PRs that need it or benefit from it.

The cases you mentioned can either be considered as

OK => UP => no notification or
not OK => DOWN => issue notification

=> don't currently see an iminent need for adding another status

@CommanderStorm commented on GitHub (Jun 7, 2024): Think that this is an implementation specific thing => should be handled in the respecitive PRs that need it or benefit from it. The cases you mentioned can either be considered as - OK => `UP` => no notification or - not OK => `DOWN` => issue notification => don't currently see an iminent need for adding another status

deekerman commented

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

Author

Owner

@casperdcl commented on GitHub (Jun 10, 2024):

sure, but it would be nice to have finer-grained severity options

see e.g.

https://docs.statuspal.io/platform/incidents-and-maintenance/custom-incident-types
https://githubstatus.com which often marks things as degraded (slow) rather than outright down:

@casperdcl commented on GitHub (Jun 10, 2024): sure, but it would be nice to have finer-grained severity options see e.g. - https://docs.statuspal.io/platform/incidents-and-maintenance/custom-incident-types - https://githubstatus.com which often marks things as degraded (slow) rather than outright down: ![FFOzbgHWYAMPMSQ](https://github.com/louislam/uptime-kuma/assets/10780059/f328fdeb-949d-4278-8c04-637241e7931c)

deekerman commented

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

Author

Owner

@LordLumineer commented on GitHub (Aug 3, 2025):

Is there any update on this topic ? this is something I would be really interested in

@LordLumineer commented on GitHub (Aug 3, 2025): Is there any update on this topic ? this is something I would be really interested in

deekerman commented

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

Author

Owner

@rasmuscnielsen commented on GitHub (Oct 10, 2025):

Just wanted to chime in here and mention that we have a lot of use cases for "degraded service" status across our stack of services.

They all fall in the category of "The service is operating, but there are likely things that should be addressed".

Examples:

There are customer orders that have been stuck too long in "processing" or "failed" and needs intervention
New vulnerabilities found in dependencies in need of update
Upstream services unhealthy (but aren't owned by us)
Abnormal activity showing potentially undergoing attacks (but service still operating)
Failure of other custom health checks showing if the system is performing and looking healthy (but not DOWN if unhealthy)

Each of our services has its own health dashboard with different checks which can be either Green / Yellow / Red. Right now, yellow + red causes DOWN in uptime kuma, often causing a lot of "downtime" which has the unfortunate side-effect of signaling a service is down even when it's not. But changing it to not flag our "warnings" would leave us in the dark when something happens that might need our attention.

The ability to signal degraded service in uptime kuma + customize alert-settings for these would be the final missing piece for us, in this otherwise absolutely fantastic and beautiful product ❤️

@rasmuscnielsen commented on GitHub (Oct 10, 2025): Just wanted to chime in here and mention that we have **a lot** of use cases for "degraded service" status across our stack of services. They all fall in the category of "The service is operating, but there are likely things that should be addressed". Examples: - There are customer orders that have been stuck too long in "processing" or "failed" and needs intervention - New vulnerabilities found in dependencies in need of update - Upstream services unhealthy (but aren't owned by us) - Abnormal activity showing potentially undergoing attacks (but service still operating) - Failure of other custom health checks showing if the system is performing and looking healthy (but not DOWN if unhealthy) Each of our services has its own health dashboard with different checks which can be either Green / Yellow / Red. Right now, yellow + red causes DOWN in uptime kuma, often causing a lot of "downtime" which has the unfortunate side-effect of signaling a service is down even when it's not. But changing it to not flag our "warnings" would leave us in the dark when something happens that might need our attention. The ability to signal degraded service in uptime kuma + customize alert-settings for these would be the final missing piece for us, in this otherwise absolutely fantastic and beautiful product ❤️