Status page says only degraded performance. It's a nice way of putting it. I'm trying to run github action for couple of hours now. They don't work at all. But apparently this means they run, but in infinite time, hence == degraded performance, nice.
GitHub incident 2022-03-23
171–180 of 206 posts
Re: GitHub incident 2022-03-23
#172Earlier quoted context omitted.
That's SRE lingo --> https://sre.google/sre-book/managing-incidents/
It's also itil lingo, which predates sre.
Re: GitHub incident 2022-03-23
#173It seems like we haven't had a non-robot status update on the status page in days since this what seems like daily occurrence. I figure at this point we'd get something of why this is happening. I also don't appreciate our builds freezing, unable to be cancelled and then eating up hundreds of minutes.
Billing should always be built on a "ping" IMO and not start/stop hooks. The latter is shockingly bad for customers during times of unreliability. The former sounds stupid and requires more infrastructure from the one offering the service, but I think it's more fair. I haven't used GA in a way where it actually costed me anything, but having minutes just tick away while you can't do anything is really stupid if that'…
At what rate would you do these pings? I don't know how upgrading/downgrading works at GitHub but if they do any sort of refund/credit when you downgrade, it seems like there's some interesting implications for abusing the system (e.g. upgrading/downgrading between pings for "free" service if the time between them is too long) versus performance (e.g. how do you update all users per ping in a timely manner if the time between them is too short?).
Would love to read up more on this approach; seems interesting!
Re: GitHub incident 2022-03-23
#174I hope they figure out what’s going on every morning. Heard from inside they don’t know why the db dies everyday but restarting it fixes it.
Yuck. Honestly, restarting a database to fix a major outage sounds like "we have no idea what we're doing"
Re: GitHub incident 2022-03-23
#175Earlier quoted context omitted.
Stop being a customer of crappy vendors
What cloud provider does better status pages than AWS?
Re: GitHub incident 2022-03-23
#176Re: GitHub incident 2022-03-23
#177https://www.githubstatus.com/history 21 incident outages in just 3 months. At this rate the benefits of running your own gitea or gitlab are starting to become competitive.
And whom pays for fixing it? Downtimes of self hosted systems using external software can be far longer. GitHub, unlike Amazon and friends, doesn't lie about their downtime. Every saas has hundreds of downtime instances across the board every month. Some are small enough you don't see them. Yet the services still work exceptionally well - and when they don't they get fixed in a quick manner. What takes them an hour w…
If you're using GitHub in Europe or Asia it's not uncommon for GitHub to be offline for many hours before they acknowledge anying.
Re: GitHub incident 2022-03-23
#178Earlier quoted context omitted.
Oh I thought it was about the one from yesterday :)
Are their CI/CD toys that shiny that people still willingly choose them even with all the issues? I find myself regularly asking this — about every major SaaS used for critical ops stuff like this.
Re: GitHub incident 2022-03-23
#179I hope they figure out what’s going on every morning. Heard from inside they don’t know why the db dies everyday but restarting it fixes it.
Yuck. Honestly, restarting a database to fix a major outage sounds like "we have no idea what we're doing"
Re: GitHub incident 2022-03-23
#180Earlier quoted context omitted.
Excluding ones reported as [Errors], [Scheduled] or [Notifications] 2019 -> 39 Incidents 2020 -> 67 Incidents 2021 -> 86 Incidents 2022 -> 20 Incidents so far Edit: Using Linear Regression...Prediction for total end 2022: 111 Incidents.
thats not the kind of progression you like to see - that is, error rates increasing over time instead of decreasing.