upvote
The August 17 outage, and the work ahead

(github.blog)

"We are committed to fixing these problems, as long as it doesn't involve buying things other than AI computers, hiring humans, or using non-Microsoft products."

Calling Azure the solution to this problem when it is in fact the source of most of these problems is just fantastic doublespeak.

Github is ripe for disruption and I hope it is disrupted soon.

reply
> We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure.

And from the RCA [1]:

> The immediate cause of the failure was network saturation on load balancers in Central US due to a new peak in traffic.

[1]: https://www.githubstatus.com/incidents/zkxwbgr0cnmx

reply
"While accelerating our migration to Azure," meaning, they will only solve problems if it helps them also use Azure more.

It is unbelivable that aload of 2.8b commits was totally fine, and a load of 2.9b was a sitewide outage, unless they have no reporting or their tooling is completely incompetent. If things can fall apart so easily, throwing more capacity at the problem won't fix it.

reply
You’re torturing your own logic to make Azure the villain here. And it also sounds like you lack experience with capacity exhaustion. Things fail slowly, then suddenly.
reply
No, I am calling Github disingenuous liars with poor motives, offering an unbelivable explanation. Not sure where the torture is, except in their statement.

If it was failing slowly, why didn't they fix it then? Why didn't they notice?

Could it be because they fired all the people who know how to monitor and identify such problems? That's what SREs are for.

reply
Baseless accusation made from a position of zero information.
reply
Opinion based on stated facts.

Please share the information you have which contradicts the conclusions I have drawn from Github's statement.

(And we know they're liars. They report very few of the actual incidents they have; see for example https://mrshu.github.io/github-statuses/)

reply
> Github is ripe for disruption and I hope it is disrupted soon.

It's an expensive, low revenue generating site.

There are, and have always been, competitors, including "host it all yourself" solutions, but nothing has really stuck.

How is it "ripe" for disruption?

reply
They had $1b revenue in 2023 and now probably more than $2b in revenue... do you have cost figures showing what their expenses are?
reply
> We have since added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity. We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure.

That can't be cheap.

reply
If you're a big company, you can afford having one engineer spend one or two days per year to maintain your self-hosted GitLab or Forgejo. On top of better reliability than GitHub, you'll get the additional bonus that your source code won't accidentally leak through being in Copilot's training set.

If you're a hobbyist, Codeberg is great, has a nice community and automatically shields you from slop contributions.

reply
The issue with these systems is that they lack Github's sophistication for issue tracking, knowledge transfer, and automation. I think Gitlab is a mature product in its own space and unlikey to change, for instance, at this point.

Codeberg also has the issue of having a political stance which means they will not accept just anyone's use of the platform. That is absolutely their right and I have no issue with it, but it's unattractive to me - as someone who agrees with most of their current politics - because the day they decide they don't like me, I'm screwed.

reply
I never found GitHub's systems for issue tracking to be all that great. Cross-repository issues and development plans are hard to track within a git host. I've always used an external panning and issue tracking tool, mostly Linear, and it works really well. GitLab's Linear integration is excellent, FWIW.

I've actually worked with a couple of companies who do use GitHub for their code, and they all use Linear in addition to GitHub.

I understand the concern you're talking about wrt. Codeberg, but I wouldn't view it as a significantly bigger risk than anything else. Any platform can suddenly decide that your project is against ToS (GitHub will absolutely not accept just anyone's use of their platform either) and Codeberg introducing some rules recently doesn't, in my mind, drastically increase the risk of a dramatic ToS change in the future. But we all have to make our own risk evaluations and I won't judge yours. Luckily, moving between Git hosts isn't that difficult; setting up CI again and losing merge request history does suck but it's not the end of the world, unlike something like, say, losing your AWS/GCP/whatever account.

reply

  "Since April, monthly commits have grown from 1.4 billion to 2.9 billion. "
Wow, that is some incredible growth in a really short time.
reply
It really is. I know I've gone from tens a month to thousands a month. They have to be projecting >100B/month in the next year or two.
reply
> Errors in those services triggered a client-side retry loop that increased traffic during recovery.

The worst outages I've been part of always have some version of this :(

reply
the 'ol thundering herd problem...
reply
Great read - I'm glad they realize there's work ahead but what I'm missing is: * Paid customers: we know you pay us often a ton of money, and we burn your month on actions during these outages - we'll refund you for the days we spent your money and gave you no value. * Paid customer: We know you put your trust in us, so we'll ensure we have a separate pool of capacity to ensure we can keep that trust. * Paid customer: we'll proactively refund you when we miss our SLA.

What I read from this is: * Scaling is hard, we don't have enough capacity * We give away a shitton of compute for free * I have to talk about Azure not being a steaming pile of poop, otherwise my bonus will get tweaked downward in the next comp cycle.

Notice there's nothing about paid customers, I'll add in what they are missing:

Paid customers: Go F*ck yourself, you don't pays us enough to be an interesting line item compared to windows server.

reply
AWS CloudWatch has an option to show the trend and what it will be like after x-period.

Doesn't Azure have such options so that engineers can predict to scale better? Seems like engineers are not ready for this per postmortem

reply
The trend line does not tell you what will actually happen at scale, even if you think you're perfectly prepared for the next 10% or 20% growth. As Mike Tyson put it, "everyone has a plan until they get punched in the face".
reply
I fear to ask, how archive.org keeps up to catch all those events for archiving...
reply
deleted
reply
Github down, no hard drives available, no memory available, thanks AI!

Seems like we are headed for Tech Gridlock.

reply
What they can implement is to slowdown the commit rate, rate limt or just queue-up messages not to overburden their downstream service.

I don't think GH has any of those, but just keep scaling, but that scaling failed.

Just bad architectural decisions from the postmortem.

--

It will only get worse due to AIs spawning massive commits, and they don't have unlimited cloud resource.

They can scale but not scalable in terms of effort, resources, and $

reply
How would any of what you're saying help with this?

> The immediate cause of the failure was network saturation on load balancers in Central US due to a new peak in traffic. Originally this was caused by an Istio sidecar pod reaching its concurrency limits and failing to auto scale correctly because of a misconfigured policy that watched host service but not sidecar limits. One failure cascaded to more and eventually four HAProxy nodes exhausted their flow limits, degrading the gateway auth path and causing widespread authentication latency and failures. The problem was worsened by optimistic retry logic which overloaded internal load balancers. Pausing HAProxy on those nodes simultaneously produced immediate broad recovery.

reply
This stuff is good! This is what a booming economy looks like. There are people out there competing with you for resources because they have cool ideas they want to implement.
reply
We need to have a package of FLOSsoftware that you could run on the cloud of your choice that offers most of what GitHub does (niceties on top of Git) without the centralization.

GitLab was close last I remember but there was some sort of enterprise tier when I tried hosting stuff on a local server years ago. I want true FLOSS, not another SaaS equivalent of the coke dealer giving clients the good uncut stuff when they're just starting out only to sell crap when they're addicted.

reply
https://forgejo.org/ promises to be this, have only lightly used it on https://codeberg.org/ but it seems nice?
reply
Have you looked into Forgejo?
reply
Exponential growth. No company could handle that without some issues. Good luck to them. And for those who cannot tolerate this, there are many self hosted options.
reply
And another outage. [0] Looking forward to the subsequent post-mortem on that one.

You might want to not go all in on GitHub anymore since it is very unstable to use. A self-hosted instance would have a far better uptime than GitHub over the years.

6 years ahead [1] on not going all in an centralizing everything on GitHub.

[0] https://www.githubstatus.com/incidents/bhbcjn4n3jzp

[1] https://news.ycombinator.com/item?id=22867803

reply
[dead]
reply
[dead]
reply
They should rewrite their Ruby code to a performant language.
reply