6 ms·

According to GH Status (https://www.githubstatus.com/ https://www.githubstatus.com/), everything is fine. Gotta love functional status pages. edit: Nevermind,

by lnsp 5y ago

According to GH Status (https://www.githubstatus.com/ https://www.githubstatus.com/), everything is fine. Gotta love functional status pages. edit: Nevermind, they just reported "degraded performance" for GitHub Actions, Issues, and Pull Requests.

rossmohax 5y ago
Didn't they have actual error rate graphs on that page back in a day?
- speedgoose 5y ago
  Yes, and some response times too. It was actually useful.
agomez314 5y ago
i wonder how they even work? Like, do they just display a green css button instead of _actually_ doing a healthcheck?
- deleted 5y ago
  [deleted]
- drstewart 5y ago
  Probably requires manual updates. It seems like more and more places have moved to this paradigm now that status pages are tied to SLAs which are tied to money. One might call it the politicization of status pages.
  - asciimike 5y ago
    Correct. SLAs aren't calculated off status pages, there are far better ways of calculating it (running a query over responses, for example). Most modern SLAs are customer initiated anyways, so the customer is writing in to request this rather than automatically calculating them. The status page doesn't need to show anything for a customer to provide logs indicating a QoS less than that promised in the SLA. I don't think it's politics (maybe AWS's is, but GCP wasn't IMO), it's really a function of "in large scale software systems things are constantly failing in all sorts of ways, and it's really hard to output a meaningful automated signal that things are broken. Sure you can set up pingdom type health checks on every endpoint, but even then you're not necessarily guaranteeing that things are working properly. Source: worked at a few cloud providers, paid out a few SLA violations
  - deathanatos 5y ago
    Politicization, yes; I've never heard of SLAs being tied to status pages. It is like pulling teeth to get most cloud providers to credit the account when they don't meet SLA, and one always has to ask for it; heaven forbid if credits were paid out automatically when service wasn't rendered. Or you get weasel-worded out of it. I had a cloud provider deny a service credit; the SLA stated that the service was only out of SLA if it didn't return 2xx. Well, the API returned "2xx Accepted — your request is being processed", and you could use the API to query the job, and the job … never finished or made any progress at all. But the API returned 2xx the entire time, so that was "within SLA".
- mkl95 5y ago
  AWS do the same thing. Pretty sure someone updates it manually.
- aseipp 5y ago
  Yes they do, because very rarely would such a healthcheck kind of setup actually work in practice, at a large enough size, for a user-facing dashboard. If you want a healthcheck, look at a Grafana dashboard, not a status page. By the way, I don't know of a single place where this isn't the case, where a human signs off on and updates the status page during large events (at least at the final decision.) Some of it will be automated, sure, like red flags being raised to operators. But at a certain point it is not possible to automate this in some level to achieve second-level accuracy or whatever; the system is rarely (if ever) in a binary state of "working perfectly" or "not working", but somewhere in between. You can't just fire off a big red error bar every time a blip occurs at a place like GitHub. The system is constantly "in motion". The logical conclusion is to just expose your 50+ Grafana dashboards publicly to every user. Isn't that the most honest "overview" of what is happening with your product? Except this often can't tell them useful things either. People on here will also mumble about SLAs but if a customer wants a kickback or is seriously worried about events like these, they're generally talking to account managers, not posting on internet forums. That said, a lot of them get weaselly about that stuff unless you're already negotiating prices with an AM in the first place...
  - lamontcg 5y ago
    When I started work at Amazon in 2001 we had a "gonefishing" page for outages that a human had to flip the site to manually. We actually stopped doing this a year or two later because reporters were setting up monitoring on that page showing up and were reporting on outage statistics based on it. So we just left the site up in whatever degraded state it was in and that made the problem of measuring www.amazon.com uptime externally that little bit more difficult.
YPCrumble 5y ago
- diogenesjunior 5y ago
  You gonna sue them?
- mirekrusin 5y ago
  Maybe they run it from github actions?
- nefasti 5y ago
  Fraud implies intent.
- na85 5y ago
  Not a lawyer, but my understanding of this issue is that it constitutes fraud if and only if the status page is a contractually- or legally-binding warrant as to the status of their services. >why is it legal in the tech industry? Tech has a history of abusing legal gray areas or else simply ignoring laws it finds inconvenient, enabled by toothless and sluggish enforcement, and using profits from lawbreaking to fund lobbying campaigns to retro-actively make things legal. For recent examples see Uber, Airbnb, Clearview, et al.
- lowercased 5y ago
  It seemed like a good faith effort... Between when I was told about it (which seemed like it was very early on) to when I saw the status page change (saw it 'all clear' at first) was... 3 minutes? Yes, it's not 'real time' but they don't seem to be intentionally hiding something for hours on end. There may be some consequences for reporting on false positives too quickly as well.
- heipei 5y ago
  I can't imagine the status page is mentioned anywhere in the contracts. I would think that the only language that is included is that it's the customers responsibility to track and notify the vendor (Github) about any downtime, and to do that within 48 hours of the downtime having occured. And only then will the customer be eligible for compensation, probably in the form of free service credits. My personal take is that this wording is the reason you see so few public status pages in general, especially ones with automatic and minute-by-minute status history. Better to put it on the customer to have accurate monitoring in place, which most people simply won't have.
sc90 5y ago
They have updated it.

by lnsp 5y ago

rossmohax 5y ago

Didn't they have actual error rate graphs on that page back in a day?

speedgoose 5y ago
Yes, and some response times too. It was actually useful.

agomez314 5y ago

i wonder how they even work? Like, do they just display a green css button instead of _actually_ doing a healthcheck?

deleted 5y ago
[deleted]
drstewart 5y ago
Probably requires manual updates. It seems like more and more places have moved to this paradigm now that status pages are tied to SLAs which are tied to money. One might call it the politicization of status pages.
- asciimike 5y ago
  Correct. SLAs aren't calculated off status pages, there are far better ways of calculating it (running a query over responses, for example). Most modern SLAs are customer initiated anyways, so the customer is writing in to request this rather than automatically calculating them. The status page doesn't need to show anything for a customer to provide logs indicating a QoS less than that promised in the SLA. I don't think it's politics (maybe AWS's is, but GCP wasn't IMO), it's really a function of "in large scale software systems things are constantly failing in all sorts of ways, and it's really hard to output a meaningful automated signal that things are broken. Sure you can set up pingdom type health checks on every endpoint, but even then you're not necessarily guaranteeing that things are working properly. Source: worked at a few cloud providers, paid out a few SLA violations
- deathanatos 5y ago
  Politicization, yes; I've never heard of SLAs being tied to status pages. It is like pulling teeth to get most cloud providers to credit the account when they don't meet SLA, and one always has to ask for it; heaven forbid if credits were paid out automatically when service wasn't rendered. Or you get weasel-worded out of it. I had a cloud provider deny a service credit; the SLA stated that the service was only out of SLA if it didn't return 2xx. Well, the API returned "2xx Accepted — your request is being processed", and you could use the API to query the job, and the job … never finished or made any progress at all. But the API returned 2xx the entire time, so that was "within SLA".
mkl95 5y ago
AWS do the same thing. Pretty sure someone updates it manually.
aseipp 5y ago
Yes they do, because very rarely would such a healthcheck kind of setup actually work in practice, at a large enough size, for a user-facing dashboard. If you want a healthcheck, look at a Grafana dashboard, not a status page. By the way, I don't know of a single place where this isn't the case, where a human signs off on and updates the status page during large events (at least at the final decision.) Some of it will be automated, sure, like red flags being raised to operators. But at a certain point it is not possible to automate this in some level to achieve second-level accuracy or whatever; the system is rarely (if ever) in a binary state of "working perfectly" or "not working", but somewhere in between. You can't just fire off a big red error bar every time a blip occurs at a place like GitHub. The system is constantly "in motion". The logical conclusion is to just expose your 50+ Grafana dashboards publicly to every user. Isn't that the most honest "overview" of what is happening with your product? Except this often can't tell them useful things either. People on here will also mumble about SLAs but if a customer wants a kickback or is seriously worried about events like these, they're generally talking to account managers, not posting on internet forums. That said, a lot of them get weaselly about that stuff unless you're already negotiating prices with an AM in the first place...
- lamontcg 5y ago
  When I started work at Amazon in 2001 we had a "gonefishing" page for outages that a human had to flip the site to manually. We actually stopped doing this a year or two later because reporters were setting up monitoring on that page showing up and were reporting on outage statistics based on it. So we just left the site up in whatever degraded state it was in and that made the problem of measuring www.amazon.com uptime externally that little bit more difficult.

YPCrumble 5y ago

diogenesjunior 5y ago
You gonna sue them?
mirekrusin 5y ago
Maybe they run it from github actions?
nefasti 5y ago
Fraud implies intent.
na85 5y ago
Not a lawyer, but my understanding of this issue is that it constitutes fraud if and only if the status page is a contractually- or legally-binding warrant as to the status of their services. >why is it legal in the tech industry? Tech has a history of abusing legal gray areas or else simply ignoring laws it finds inconvenient, enabled by toothless and sluggish enforcement, and using profits from lawbreaking to fund lobbying campaigns to retro-actively make things legal. For recent examples see Uber, Airbnb, Clearview, et al.
lowercased 5y ago
It seemed like a good faith effort... Between when I was told about it (which seemed like it was very early on) to when I saw the status page change (saw it 'all clear' at first) was... 3 minutes? Yes, it's not 'real time' but they don't seem to be intentionally hiding something for hours on end. There may be some consequences for reporting on false positives too quickly as well.
heipei 5y ago
I can't imagine the status page is mentioned anywhere in the contracts. I would think that the only language that is included is that it's the customers responsibility to track and notify the vendor (Github) about any downtime, and to do that within 48 hours of the downtime having occured. And only then will the customer be eligible for compensation, probably in the form of free service credits. My personal take is that this wording is the reason you see so few public status pages in general, especially ones with automatic and minute-by-minute status history. Better to put it on the customer to have accurate monitoring in place, which most people simply won't have.

sc90 5y ago

They have updated it.