Live data from Hacker News

GitHub incident 2022-03-23

githubstatus.com

171–180 of 206 posts

Re: GitHub incident 2022-03-23

#171

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.

It's just a way to avoid SLA breaches. "Of course it wasn't down! It was just infinitely slow!"

Re: GitHub incident 2022-03-23

#172
post #76

Earlier quoted context omitted.

That's SRE lingo --> https://sre.google/sre-book/managing-incidents/

It's also itil lingo, which predates sre.

It's NIMS - FEMA lingo, which predates ITIL. Which was developed in USFS wildland firefighting, which predates FEMA. It's incident management all the way down.

Re: GitHub incident 2022-03-23

#173

It 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'…

The "ping" solution is an interesting one that I haven't seen proposed before.

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

#174

I 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"

Sporadic database performance issues can certainly make you feel that way. They are definitely not trivially debugged at scale

Re: GitHub incident 2022-03-23

#175

Earlier quoted context omitted.

Stop being a customer of crappy vendors

What cloud provider does better status pages than AWS?

The snarky answer is "literally all of them", but one real answer is that I've been pretty happy with GCP's status reporting for the past year-ish I've used them. I've only noticed a few incidents, but every time I've checked the status it was already updated. They also occasionally provide workarounds on the live incident pages if you need to be back up before the issue is fixed on their end.

Re: GitHub incident 2022-03-23

#176

Earlier quoted context omitted.

I doubt they use IIS

MSer here, yes we do… for some things

If GH is around the same level of integration with Microsoft as my employer, which is another Microsoft acquisition, I don't really believe you have a ton of insight into GH processes.

Re: GitHub incident 2022-03-23

#177
post #16

https://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…

GitHub is notorious for only noticing outages once the USA morning starts.

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

#178

Earlier 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.

Work choose GitHub (we are a MicroSoft shop), I have to say, I like GitHub a lot. The disruptions have been annoying sometimes, that's true. But due to the nature of Git I could always just keep working.

Re: GitHub incident 2022-03-23

#179

I 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"

Would you rather it stay down while they spend a day debugging it?

Re: GitHub incident 2022-03-23

#180
post #84
post #39

Earlier 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.

Reasonable if growth/load is growing, too.
Post reply on HN