Additional control of "Operational Status" when incident is created #549

Closed
opened 2026-02-28 01:50:14 -05:00 by deekerman · 3 comments
Owner

Originally created by @gardium90 on GitHub (Nov 10, 2021).

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

  • I checked and didn't find similar feature request

🏷️ Feature Request Type

UI Feature

🔖 Feature description

Apologies if this already is somewhere, I couldn't find it.

I have deployed this monitor in the infrastructure of a large company. We love it! However, as a "public uptime tracker status" page, it isn't always that the pings and HTTPS codes accurately can reflect our system status. This seems to be handled nicely by the ability to create "incidents" that can be nicely flaired with a color.

What isn't so great, is when you have a large red bubble saying you have an outage or issue, and then the "operational status" is all green and happy.

✔️ Solution

Proposing the ability that when incidents are pinned/open on the status page, that the "operational status" bar enters a mode where the operator has 4 choices: Operational, Degraded, Failed (sorry, can't recall of the top of my head the last status), and then also Auto if the operator doesn't want to set this manually.

But is just is confusing to see "operational issue is known" and a green or yellow status field when the bubble on top is red.

Alternatives

Or, if it is not wanted to give operators such control, at least make the "operational" status match the color of the bubble if it is one of the three (green, yellow or red).

📝 Additional Context

No response

Originally created by @gardium90 on GitHub (Nov 10, 2021). ### ⚠️ Please verify that this feature request has NOT been suggested before. - [X] I checked and didn't find similar feature request ### 🏷️ Feature Request Type UI Feature ### 🔖 Feature description Apologies if this already is somewhere, I couldn't find it. I have deployed this monitor in the infrastructure of a large company. We love it! However, as a "public uptime tracker status" page, it isn't always that the pings and HTTPS codes accurately can reflect our system status. This seems to be handled nicely by the ability to create "incidents" that can be nicely flaired with a color. What isn't so great, is when you have a large red bubble saying you have an outage or issue, and then the "operational status" is all green and happy. ### ✔️ Solution Proposing the ability that when incidents are pinned/open on the status page, that the "operational status" bar enters a mode where the operator has 4 choices: Operational, Degraded, Failed (sorry, can't recall of the top of my head the last status), and then also Auto if the operator doesn't want to set this manually. But is just is confusing to see "operational issue is known" and a green or yellow status field when the bubble on top is red. ### ❓ Alternatives Or, if it is not wanted to give operators such control, at least make the "operational" status match the color of the bubble if it is one of the three (green, yellow or red). ### 📝 Additional Context _No response_
Author
Owner

@Coderdude112 commented on GitHub (Nov 22, 2021):

This would be a nice feature +1

@Coderdude112 commented on GitHub (Nov 22, 2021): This would be a nice feature +1
Author
Owner

@codeagencybe commented on GitHub (Nov 25, 2021):

where the operator has 4 choices: Operational, Degraded, Failed (sorry, can't recall of the top of my head the last status)

That last one is typically "Partial outage" and/or "Full outage"

@codeagencybe commented on GitHub (Nov 25, 2021): > where the operator has 4 choices: Operational, Degraded, Failed (sorry, can't recall of the top of my head the last status) That last one is typically "Partial outage" and/or "Full outage"
Author
Owner

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

@gardium90
We are consolidating duplicate issues a bit to make issue management easier.
I think, we should track this issue in #908. I have updated said description slightly to inlcude this issue.
⇒ I am going to close this as a duplicate.

@CommanderStorm commented on GitHub (Dec 4, 2023): @gardium90 We are consolidating duplicate issues a bit to make issue management easier. I think, we should track this issue in #908. I have updated said description slightly to inlcude this issue. ⇒ I am going to close this as a duplicate.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/uptime-kuma#549
No description provided.