| ▲ | arn3n 10 hours ago |
| What do we think is more to blame for GitHub's massive decrease in quality? I've heard the following theories: 1. Increasing amount of AI-generated code in their codebase, decreasing the quality of the service. 2. Bought by Microsoft, and their bad engineering culture has spread to GitHub. Perhaps it's a bit of both. |
|
| ▲ | celestialcheese 10 hours ago | parent | next [-] |
| Azure migration is the most plausible explanation I've heard. https://news.ycombinator.com/item?id=45517173 |
| |
| ▲ | Reason077 10 hours ago | parent | next [-] | | GitHub claims that AI development tools have caused a massive surge in demand in recent months. They need to scale by 30X to keep up with demand. According to GitHub, Azure migration is the attempt at a fix/upscaling, not the underlying cause of the issues. Addressing GitHub’s recent availability issues:
https://github.blog/news-insights/company-news/addressing-gi... An update on GitHub availability:
https://github.blog/news-insights/company-news/an-update-on-... | | |
| ▲ | plorkyeran 9 hours ago | parent | next [-] | | Github is claiming that a usage spike in 2026 is the cause of availability issues in 2025, so their explanation is clearly incomplete at best. The usage spike may be why things have failed to get better despite them putting effort into improving things, but it isn't the root cause of problems. | |
| ▲ | dijit 10 hours ago | parent | prev | next [-] | | But the outages have been getting worse and worse even before anything related to AI took off. The issue is that they're not a scrappy startup anymore, they are defacto running the internets development infrastructure and are owned by a trillion dollar company. So the bar they're measured by has changed and they haven't even tried to keep up, paying lip service to reliability when you are critical infrastructure is not going to go well. There were reliability issues in 2010 for sure, but it feels worse now; the period before acquisition was the most stable (2014-2017). | |
| ▲ | Aurornis 6 hours ago | parent | prev | next [-] | | > GitHub claims that AI development tools have caused a massive surge in demand in recent months. They need to scale by 30X to keep up with demand They said they're designing for a future that would require 30X of today's scale. They did not say that they need to scale 30X to meet today's demand. To be fair, the "demand is up 30X" claim was spammed all over social media so it's easy to see why this topic is so misunderstood | |
| ▲ | aforwardslash 5 hours ago | parent | prev | next [-] | | Funny how windows updates are never postponed for lack of "scaling". I know, I know, completely different stuff here - but arent test vms and ci vms being updated constantly? Im old enough to remember the hotmail migration to win2k (then 2k3) and the postmortem. I was also old enough to look at the rotor source code. Yah, that one, running managed code in freebsd. | |
| ▲ | vvillena 10 hours ago | parent | prev | next [-] | | Their own greed is causing their issues. They could be doing a million different things to reduce demand, but they don't want to dampen their current growth and have opted to continue scaling up at the cost of quality. | | |
| ▲ | omosubi 9 hours ago | parent [-] | | What would you suggest they do to reduce demand? (This is a serious question btw) | | |
| ▲ | jitl 6 hours ago | parent [-] | | They could make people pay for stuff that is free right now. |
|
| |
| ▲ | UltraSane 9 hours ago | parent | prev | next [-] | | If demand increased that much they should be imposing rate limits. | |
| ▲ | duped 7 hours ago | parent | prev [-] | | Then they shouldn't be encouraging AI development tool usage. I've never pushed a commit and thought huh, I wonder what copilot thinks of this. |
| |
| ▲ | btown 9 hours ago | parent | prev | next [-] | | Coupled with this (unsubstantiated but thorough) discussion on the internals of Azure, if even a fraction of this below-linked post is true, Github's abnormally-filesystem-intensive workflows would have wildly unpredictable performance and reliability forced onto Azure. https://isolveproblems.substack.com/p/how-microsoft-vaporize...
https://news.ycombinator.com/item?id=47616242 | |
| ▲ | Nemo_bis 9 hours ago | parent | prev | next [-] | | Azure also regularly has incidents due to capacity issues in several regions, so that many Azure-managed services also go down. Some of those incidents have been open continuously for many months now. | |
| ▲ | ergocoder 4 hours ago | parent | prev | next [-] | | OMG I was a few FAANG-like companies. Most acquisitions failed due to the migration. It always played in the same way: 1. The acquired company was small company to the acquirer.
2. We need to improve scalability and reduce cost! Then, they migrated. The new system was worse and didn't have parity. It was years. Customers were moving off. The project/product shut down. | |
| ▲ | dgb23 10 hours ago | parent | prev [-] | | I glanced at zhe thread you linked. And as I understand they are in the process of migrating, which will take more than a year still. If that’s the case, then it’s not necessarily a problem with Azure itself. |
|
|
| ▲ | carlos-menezes 10 hours ago | parent | prev | next [-] |
| I'd add a third point: record service usage. https://github.blog/news-insights/company-news/an-update-on-... |
| |
| ▲ | marginalia_nu 10 hours ago | parent | next [-] | | We don't have a labeled y-axis so their record usage could be a 5% increase for all they're showing us. | | |
| ▲ | weiliddat 10 hours ago | parent [-] | | I think it doesn't need to be a large X% increase, just needs to hit some critical infra threshold where various services start failing and cascade. Weakest link and everything. |
| |
| ▲ | sureglymop 10 hours ago | parent | prev | next [-] | | It interestingly shows how a centralized system may just fail or become too flaky at unprecedented growth. I suppose it's a bit too on the nose to point out that git is decentralized and itself doesn't really suffer from this, nor need it. | |
| ▲ | arianvanp 10 hours ago | parent | prev | next [-] | | And yet GitHub has felt the most dead it ever did. Less quality contributions. Less feeling of community. All the open source projects are struggling. They dont have a service usage problem they have a slop problem. Ban the slop and the platform will thrive | | | |
| ▲ | 10 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | IshKebab 10 hours ago | parent | prev [-] | | Yeah if those graphs are even vaguely accurate there's really only one explanation: vibe coders pushing previously unimaginable amount of slop. I would not be surprised if Github has to stop offering so many services for free. | | |
|
|
| ▲ | campbel 10 hours ago | parent | prev | next [-] |
| It's been on a downward trend before agentic coding took over. I suspect it's a mix of Microsoft culture and Microsoft infrastructure. It's starting to feel about the same quality as other Microsoft services. Short aside, I have to rehost dotnet CLI binaries because their hosting infrastructure is so unreliable that it was causing CI failures regularly. |
| |
| ▲ | dijit 10 hours ago | parent [-] | | I suppose there's a reason that most Microsoft development shops tend to vendor their dependencies as a culture. Gamedev being the most prominent that I have personally witnessed. EDIT: Why are you booing me, I'm right. |
|
|
| ▲ | PunchyHamster 10 hours ago | parent | prev | next [-] |
| It started being bad after MS. It started being very bad when MS pushed for AI |
|
| ▲ | SwellJoe 9 hours ago | parent | prev | next [-] |
| It began pretty much immediately after the acquisition. There was an uptime chart making the rounds a while back, and less than a year in, the all green data points of pre-Microsoft Github turned to lots of red. I assume brain drain, as everyone vested or otherwise completed their contractual requirements and cashed out. And, Microsoft has never had a great reliability culture in their cloud services, so no in-house talent to effectively take over. |
|
| ▲ | alexxxxxxxxxx 10 hours ago | parent | prev | next [-] |
| I would say uptime and UX/UI: uptime: Incomplete pull request results in repositoriesSubscribe
Update - We are actively reindexing the remaining ElasticSearch indexes. Our priority is ensuring correctness and avoiding further impact. We are taking a measured approach to safely backfill data and will share additional updates as progress continues.
Apr 28, 2026 - 15:58 UTC
Update - After yesterday’s incident, we are investigating cases where /pulls and /repo/pulls pages are not showing all indexed pull requests. This is because our Elasticsearch cluster does not currently contain all indexed documents. No pull request data has been lost. As pull requests are updated, they will be reindexed. We are also working on accelerating a full reindex so these pages return complete results again.
Apr 28, 2026 - 14:51 UTC
Investigating - We are investigating reports of degraded performance for Pull Requests
Apr 28, 2026 - 14:17 UTC |
|
| ▲ | cdfalcon 10 hours ago | parent | prev | next [-] |
| https://damrnelson.github.io/github-historical-uptime/ |
| |
| ▲ | rstupek 10 hours ago | parent [-] | | I'm curious if your graph had the number of projects its hosting shown as well? |
|
|
| ▲ | tfrancisl 10 hours ago | parent | prev | next [-] |
| #2 makes #1 a big problem. AI-generated code is fine if you have thorough engineering practices around it. Are they blindly merging in AI generated code without review? Maybe. Thats an issue of engineering practices, not of the use of generative AI in general. |
| |
| ▲ | saghm 9 hours ago | parent [-] | | Yeah, this is what I was going to say. These two theories are not mutually exclusive, and there's an argument that they're casually related |
|
|
| ▲ | maxvisser 10 hours ago | parent | prev | next [-] |
| Nah they must be actively moving infrastructure (to azure?) for the amount of outages they have |
|
| ▲ | mirekrusin 10 hours ago | parent | prev | next [-] |
| Not necessarily culture, it could be just forcing to migrate to azure that is not reliable, no? |
| |
| ▲ | mnau 8 hours ago | parent | next [-] | | Azure is not the best, but it mostly works. GitHub gets only 98% reliability for git operation component, reading and committing. This is the most basic component. The fact they are not on this 24/7 and it isn't fixed is the result of a culture (=what is prioritized, what quality is accepted). | |
| ▲ | cyberpunk 9 hours ago | parent | prev [-] | | I mean I know we all love to shit on azure, but I don't think it's partially unavailable for 3 hours a day on avg over the last 3 months? |
|
|
| ▲ | bayindirh 10 hours ago | parent | prev [-] |
| Note: I'm a graybeard coming from SVN era. GitHub took a massive hit in credibility when it got bought by Microsoft. We are a burned generation, we have seen the worst of Microsoft. This created a massive crack in the foundation of trust for most people. Then Copilot happened. Some people dug how the training is done, and one GitHub employee responded by mail that every public repository including GPL repositories are included (the relevant Tweets are deleted unfortunately). The created crack has deepened. Some of us (incl. me) left GitHub. As Copilot entrenched, Microsoft's product development practices and philosophy took over, and vibe coding started to be used by hordes of developers, GitHub's code foundations started to crumble. Add the big migrations they're doing & regressions they are causing on the UI now, and we're here. GitHub's first enshittification cycle is over. Now we're starting the second cycle. The bloated, slow, entrenched hegemon's decay from relevance phase. It'll be a slow decay. It won't fall in a day, but they golden era is long gone. |
| |
| ▲ | spindump8930 10 hours ago | parent [-] | | Any more context on the copilot training note? More pointers would be very interesting, but we'd need to keep in mind how many different underlying models were (are?) branded as copilot. I thought at some points the "copilot" model in autocomplete contexts was a finetuned GPT from OAI. Re: GPL, there are other open access datasets of git repos that make some distinctions between copyleft licenses but those are older resources now. | | |
| ▲ | bayindirh 10 hours ago | parent [-] | | Please see below. This is from the OG, "first generation" Copilot, from 2022. If I can find any more from my dusty trove, I'll edit or reply to this very comment. I can't do more digging now, because I'm in a pinch. > Re: GPL, there are other open access datasets of git repos that make some distinctions between copyleft licenses but those are older resources now. Arguably "The Stack" contains only permissively licensed code, but there are two repositories of mine inside it. One is a very simple logging library, without any license (which implies "All Rights Reserved"), and another is a fork of LightDM which I worked on, which is GPL licensed. So any "permissively licensed" dataset probably contains at least one copylefted or strong copyrighted codebase, making them highly suspicious. == EDIT == Found some. Kagi's date-constrained search to the rescue. 1. Should GitHub be sued for training Copilot on GPL code?: https://news.ycombinator.com/item?id=31847931 2. GitHub Copilot, with “public code” blocked, emits my copyrighted code: https://news.ycombinator.com/item?id=33226515 3. AI-Powered GitHub Copilot Leaves Preview, Now Costs $100 a Year: https://developers.slashdot.org/story/22/06/25/0334207/ai-po... 4. GitHub Copilot is trained on all languages that appear in public repositories (CTRL+F on the page): https://web.archive.org/web/20260428180443/https://github.co... |
|
|