Add different service severities in same issue about cstate HOT 15 CLOSED

Sounds like a great idea! But this seems like it would over-complicate things a tad too much, which I’m very wary of. Furthermore, this would have to be backwards compatible. So:

severity: disrupted
severityForSystems:
 - API: down

But I really don’t like this. It’s quite ugly and I can’t imagine where to begin actually making that work, how many bugs would arise, and also the many ways of creating issues (ala Netlify CMS).

Any ideas?

from cstate.

Maybe have the availability of adding an additional bit somewhere.

severity: disrupted
affected:
  - API
  - Web: down

This is probably not backwards compatible in that it would look for "Web: disrupted" on older versions. However I don't have a great answer right off the bat other than it would be great for a major version bump, which you are getting ready to introduce (v3).

We ran into this recently and created two overlapping issues to get it to show both with different looks. It worked as each issue affected different systems, but we get two issues instead of one when it was all combined.

• https://status.chocolatey.org/issues/20181107-slow-intermittent-connections/
• https://status.chocolatey.org/issues/20181107-services-down/

I can't show you what the top level looked like without creating another, but it did work where some showed orange, and some showed red with the right notes next to them.

from cstate.

Actually what about:

severity: disrupted
affected:
  - API
  - Web 
    - severity: down

If the current parser would ignore that, then that would allow it to just show API and Web as disrupted in an older version and in versions where it knows what to do with that, it could show it as API disrupted, Web down. Thoughts?

from cstate.

It's also possible we'll need to seek out a different solution as we've found it necessary to have different statuses for different areas of our architecture in an outage. Just let us know if it's something you could plan to support or if you don't want the added complexity. Either answer is fine and will help us make a decision on next steps for us. Thanks in advance!

from cstate.

Sorry, I misspoke - v4?

from cstate.

I'm not against the idea but the problem is it's not an easy task to implement so I don't know if it's worth pursuing.

Ideally you should create 2 issues because it's not often that you get 2 different results on 2 systems because of one problem.

I'm leaning on the side of simplicity for the sake of the project's stability and my sanity, but this doesn't mean that I'm not willing to work on it — might need more time to think about it, more discussion, etc.

from cstate.

That's completely understandable - I can understand a desire to keep things simple.

from cstate.

I was writing this quite long comment but it ended up being rambling more than anything. I have come to a few conclusions:

1. I don’t think this would work. For one, I have no idea how to make it work, second of all: it’s not particularly backwards compatible. You would still have to put this behind a flag in the config (‘cause this kind of syntax does not work atm) and there’s no going back if you decide to use it.

severity: disrupted
affected:
  - API
  - Web 
    - severity: down

2. What might work.

severity: disrupted # might be worth keeping
affected:
  - API: disrupted
  - Web: down

I sort of have an idea of how to accomplish this kind of setup but it’s far from backwards compatible, meaning any old incidents would have to be… I guess archived? Or maybe like set in the config that the incidents are in a new frontmatter template?

Thoughts?

from cstate.

2 could work, and would be beneficial - we may have applications that are running slower than normal, but the API could be having down/, which we would like to flag as something separate!

from cstate.

So I’m imaging this is a boolean of some sort in the config like:

enableMultipleSeverities: true

Better long term but really annoying if you already have a status page with a long history of incidents. I think I’d have to rewrite everything in the homepage to accomodate for the change, and it’s one of the most requested features seemingly! Would that be an OK solution?

from cstate.

Would this be in the config / Would this be where you link the application status or would this be listed under the issues when you create an incident?

from cstate.

Thinking config.yml - what do you mean by application status?

edit: for reference i made this https://discourse.gohugo.io/t/filtering-posts-complicated-case-of-a-status-page/18595/7

from cstate.

Update: I haven't been able to make any progress personally towards this issue and it will likely be closed at some point unless somebody decides to contribute to this. Sorry.

from cstate.

👍 Hi, i think that this could be useful for me too

from cstate.

Archiving this. It's been 2 years. See previous comments for context.

from cstate.