> Our priorities are clear: availability first That's a delayed April fool's right?
No, just a 6 month old memo that was first opened today, as they said literally the same 6 months ago.
An update on GitHub availability
101–110 of 266 posts
Re: An update on GitHub availability
#102Earlier quoted context omitted.
These are not the worst graphs in the world... Sure the bottom left axis is not labeled, but it still conveys the point correctly. The growth between 2023->2024->2025->2026 is growing quickly. And that in the end/beginning of 2026 they say more growth than the three years before, combined! You don't need to know the bottom left axis number. We do have to assume the graph is linear, and not some kind of negative expon…
> You don't need to know the bottom left axis number. We very much do. The graph suggests an insane growth in PRs from almost zero to 90M. Now compare this misleading graph with this much clearer one, which shows that the growth over the last three years has been less than 80%: https://github.blog/wp-content/uploads/2025/10/octoverse-202...
That link shows the number of PRs created to be less than 10M though.
Re: An update on GitHub availability
#103Earlier quoted context omitted.
Yeah sorry it's marketing BS speak for self-hosted or just infra that you control. It could be a VPS, it could be a Raspberry Pi at home. Your repos live on your servers. (And we support this on Tangled today!)
> just infra that you control But a VPS isn't actually infrastructure you control, you essentially have as much control over it as "cloud", so I don't think that'd be counted as "sovereign", would it?
Perhaps, but it's still better than nothing!
Re: An update on GitHub availability
#104Personally, I’m sympathetic. We know that GitHub did a huge amount of work over the last decade to make Git scale, which has benefited us all. These new scaling challenges are real challenges, 30x growth would be a nightmare for any system that was already pushing the limits of what was possible, I think we are being far too hard on GitHub, they deserve a little grace.
For all the negatives about github I agree. They offer a lot of free stuff, and LLMs seem likely to put massively increase their costs with no guarantee they'll be making money off it. I can't think of many (any?) large businesses which could scale up to meet so much new demand without some significant growing pains along the way.
Re: An update on GitHub availability
#105Availability is priority? Does not seem like it is https://mrshu.github.io/github-statuses/
Re: An update on GitHub availability
#106Earlier quoted context omitted.
recently there was a twit how GitHub PR diffs had 10 React components PER LINE. And how they optimized that to only 2 React components per line or something. > To summarize, for every v1 diff line there would be: > - Minimum of 10-15 DOM tree elements > - Minimum of 8-13 React Components > - Minimum of 20 React Event Handlers > - Lots of small re-usable React Components https://github.blog/engineering/architecture-op…
I'm asking about the infrastructure, obviously they chose for some reason to make my computer fans turn on to show some red and green lines on a text file.
terrible frontend architecture suggests poor engineering culture which typically spreads to all teams, including the infrastructure team
Re: An update on GitHub availability
#107anyone who's actually worked there, could you explain why they're finding scalability and reliability so hard? naively it seems like 'repo groups', ie clusters of repositories linked by being mutual forks, would be fairly isolated for the whole git storage layer, and everything else feels pretty easily parallelisable (issues, actions, etc, modulo taking locks now and then to submit results or whatever). and given tha…
Almost every high volume service on the internet is write a little, read a lot, and when there are writes, they're relatively small, a few bytes into a database that can fan out. GitHub is very different: constant writes, large files, it is under far more pressure than the systems the rest of us build. And then, as the article says, vibecoding happens, and suddenly they're receiving 30x the volume of expensive operations. GitHub are responsible for many of the performance improvements made to Git over the years, Git scales today because of work GitHub did, but that work was never intended to scale to volume of today.
Even as recently as 18 months ago, Lovable appeared, seemingly overnight, and caused huge problems for GitHub because they were creating repositories on GitHub for every single Lovable project, offloading the very high cost onto GitHub, hundreds of thousands of repositories. A couple of years before that, Homebrew used GitHub as a de facto CDN and that was a huge problem, too.
Nowadays it is easy to imagine how we can scale out a service like Twitter or YouTube or Facebook because everything has been done before, but that's not true of Git, Git hasn't ever scaled like this before, there are very few examples of service with GitHub's characteristics.
Re: An update on GitHub availability
#108so what they're saying is that Co-Authored-By claude@anthropic.com is overloading their systems? and that azure cannot scale fast enough to handle the load so they're embracing multi-cloud as a company... owned by microsoft? woah. what am I reading.
AI is the new DNS when it comes to service failure.
[dead]
Re: An update on GitHub availability
#109The AI agent growth explanation is interesting but also a bit of a deflection. If a meaningful portion of your traffic is now automated agents, your capacity planning model is fundamentally different, you're no longer scaling for human paced workflows but for burst patterns that look nothing like historical load.
The unlabeled graphs don't help the credibility case. When you are already in the hole on trust, shipping a post that requires readers to assume favorable baselines is exactly the wrong move.
Re: An update on GitHub availability
#110Earlier quoted context omitted.
More numbers: https://x.com/kdaigle/status/2040164759836778878 What's the question here, you don't believe growth is currently exponential, or do you think it shouldn't be hard to scale, when 10x YoY is not enough?
These numbers should have been in the blog post, not the graphs that are present. > What's the question here, you don't believe growth is currently exponential, or do you think it shouldn't be hard to scale I think you're putting words in my mouth here; I didn't say either of those things. I'm saying that this blog post is a meaningless platitude when the github stability issues predate this, and that all this post s…
Sorry if I misread your intent.
I just think their charts, taken at face value, show substantially the same thing (for PRs, commits, new repos).
Either those charts are a bald-faced lie (the tweet could be as well) or there is no way for that chart to be something else.
The only way to fake exponential growth like that would be to use an inverse log scale (which would be a bald-faced lie).
It doesn't even really matter what's the y-axis baseline, unless we really think growth was huge in 2020, then cratered to zero by 2023, now back to the previous normal.
As for the rest of the post, I do think it's panic mode platitudes. But I honestly don't know what I'd write instead that's better.
You can already see people complaining loudly where they instead of "we'll do better" decided to limit usage.