Closed soinu closed 3 years ago
An unresolved notice severity issue is automatically tagged as maintenance. (Why?)
Notice = maintenance or similar cases that don't affect the system now.
Show textbox at the top before and during maintenance period
This is a static site.
performance issues vs disrupted
What is the difference?
Why the complexity? I'm personally against performance issues as a severity for example.
I guess not showing the issue at the top could be an option, but why? Why would you not want to announce something?
It just seems like something that wouldn't help your customer.
This is a static site.
Updating the maintenance with resolved: true would mean maintenance is finished and the textbox will be removed (like it happens with notice right now, just wanted to explain it)
performance issues vs disrupted
What is the difference?
A performance issue means there might be some short hiccups. A disruption is an actual malfunction, something is really broken but the system is not completely down.
I guess not showing the issue at the top could be an option, but why? Why would you not want to announce something?
The announcement should happen, but not at the top and not forever while the issue is unresolved. It is not possible to hide the textbox without resolving the issue.
The issue / announcement is still visible in the RSS feed and on /affected/system123
. Also some performance issue text (e.g. in blue), like other status page systems have, would be shown next to the affected system.
I think most of this is too complex.
Keeping this issue open, as I'm open to ideas, for a little bit to see if other people support the idea or not.
Can you explain what exactly would be too complex? The implementation? The "end user" issue creation? Do you just don't like too many toggles (no hard feelings)? I think the explained examples are valid use cases, I have no idea why nobody else requested this yet.
Cachet and I suppose most other big status pages don't have such granual severities because they're supposed to be all encompassing
Sure
the implementation?
I'd love to write less code but if there's a need then you have to do that
The "end user" issue creation? Do you just don't like too many toggles (no hard feelings)?
Picture a burning server. Do you want to switch toggles or get to writing in the content box what's happening? I don't think admins want to think about the difference between disrupted and performance issues. I literally don't know the difference and neither will a customer of a SaaS app. If it's not working, it's not working, the only difference between down and disrupted is that with down it's really bad, for disrupted it's partially down
I think the explained examples are valid use cases, I have no idea why nobody else requested this yet.
Of course they're valid and if you need them, code them in, it's always an option that I point out. It's why I love open source
However with the project I'm not interested in making something bulkier than it needs to be for most people
Cachet has even more options which fit even more use cases. It has a status option for the issue (incident) itself and for the affected system (component).
Cachet has even more options which fit even more use cases. It has a status option for the issue (incident) itself and for the affected system.
Not bad but if you don't strictly speaking need something, I am skeptical
However with the project I'm not interested in making something bulkier than it needs to be for most people
Thanks for your detailed replies! Does this mean you wouldn't even accept a PR to implement a toggle and / or an additional severity level?
If it's not working, it's not working, the only difference between down and disrupted is that with down it's really bad, for disrupted it's partially down
Well, that's the point. Performance issue means most or everything of the system is working most of the time, but there might be hiccups
However with the project I'm not interested in making something bulkier than it needs to be for most people
Thanks for your detailed replies! Does this mean you wouldn't even accept a PR to implement a toggle and / or an additional severity level?
At the moment, no, because I've not released a new version in a while.
Personally, I want something described better than performance-issues
. Too long and it sounds too specific. So to answer your question, in principal, I understand the need and would accept a PR if there was a discussion/demand for this.
Well, that's the point. Performance issue means most or everything of the system is working most of the time, but there might be hiccups
See that just sounds like a disruption, even if you can't call it a partial outage
Personally, I want something described better than performance-issues. Too long and it sounds too specific.
Shopify uses Degraded
and Partial Outage
https://www.shopifystatus.com/
statuspage.io uses degraded performance
status.io uses Degraded Performance
, Partial Service Disruption
and Service Disruption
freshstatus from freshworks uses Degraded Performance
, Partial Outage
, Major Outage
and Maintenance
I'm closing this issue for now because after digging into the codebase where severities are used and there's tons of if
statements, I think it's irresponsible to complicate the code even more.
As I've mentioned before, I don't think having a "partially down" kind of status is important and provided my workarounds (changing language file, changing how you look at the severities themselves).
If you really need that extra severity, consider going with a different status page. I see this one as a free alternative for hobbyists and open source fans which can be separate from other infrastructure they might be using so it's a bit more of a legitimate option. Sorry, but thanks for checking out the project and taking the time to submit the idea!
Is your feature request related to a problem? Please describe. The current severity levels are quite limited.
It is not possible to create entries which affect a service but do not create a textbox at the top, for example for not so relevant performance issues or just some other general announcement for a specific system. An unresolved
notice
severity issue is automatically tagged as maintenance. (Why?)Describe the solution you'd like Restructure severity levels:
maintenance
resolvedWhen
andresolved: false
Maintenance
behind affected systems during maintenance period (and not already before like when usingnotice
at the moment)notice
performance-issues
disrupted
down
Describe alternatives you've considered
Add an additional toggle for showing the issue at the top in the textbox and a new
performance-issues
severity. This would ad support for some more cases and is probably easier to implement