[flagged]
An update on GitHub availability
131–140 of 266 posts
Re: An update on GitHub availability
#132Hah, love that now they say "Our priorities are clear: availability first, then capacity, then new features" when 6 months ago, it was seemingly exactly the same except Azure supposedly was gonna save them: > GitHub Will Prioritize Migrating to Azure Over Feature Development - GitHub is working on migrating all of its infrastructure to Azure, even though this means it'll have to delay some feature development. > In a…
It's entirely possible the move to Azure has made the availability problems worse. Dedicated hardware is much more predictable than cloud. "Let's not move to Azure and instead buy a few more racks" was likely a decision beyond the pay grade of github's management.
Re: An update on GitHub availability
#133I have a hard time believing anything what's said in a blog post where a graph lacks axes labels/scale. It tells me that nobody who cares about correctness had any say on the content of the post. Maybe I'm being 8am cranky and pedantic, but I'm sticking with it. > availability first, then capacity, then new features. I'd love to experience first-hand a leadership team who says, "stop accepting new paying customers un…
Like they did with Copilot last week? https://github.blog/news-insights/company-news/changes-to-gi...
> New sign-ups for GitHub Copilot Pro, Pro+, and Student plans are paused. Pausing sign-ups allows us to serve existing customers more effectively.
Re: An update on GitHub availability
#134blame MySQL. Blame Ruby.
on another note - is the exponential growth from 'agentic' workflows actually resulting in productive software in the wild. Or it is just noise. On my end I haven't seen the software I use getting better.
Re: An update on GitHub availability
#135Earlier quoted context omitted.
But, there are? I can host a repo on GitHub, Codeberg and self host it too. Then I need to watch over main to keep it consistent between those. After that's established, I can do updates from wherever. Link'em in the README.
There's also a tool to automatically push it to multiple repos: https://github.com/prashantsengar/GitEcho Disclaimer: the author is a colleague of mine Though to be fair, what the parent meant by federated forges is different than this approach.
git itself can push to multiple URLs btw:
https://stackoverflow.com/questions/849308/how-can-i-pull-pu...
Re: An update on GitHub availability
#136Earlier quoted context omitted.
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 matt…
No problem - it's tough online sometimes.
> I just think their charts, taken at face value, show substantially the same thing (for PRs, commits, new repos).
The problem is that these charts show the massive exponential growth in 2026. But this didn't start in 2026, this has been going on since early last year. My team had more build failures in 2025 due to actions outages or "degraded performance" than _any other reason_ and that includes PR's that failed linting or tests that developer were working on.
> 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.
IMO, this needed to be written a 6 months ago (around the time that the memo of them prioritising the migration to Azure was released), and then this post should have been "We're still struggling, this isn't good enough. Here's the amount of growth, here's what we've done to try and fix it, and here's what we're planning over the next 3-6 months", instead of "Our priorities are clear: availability first, then capacity, then new features" and "We are committed to improving availability, increasing resilience, scaling for the future of software development, and communicating more transparently along the way." This isn't transparency (yet).
Re: An update on GitHub availability
#137Two incidents? Just two?
In seriousness, looking at their scale, this is an insane engineering challenge.
Especially if they’re moving databases, not easy ever, and certainly not at that scale
Re: An update on GitHub availability
#138As a solo dev GitHub going down is scary all my code, all my history, one platform. This makes me want to keep local backups more seriously.
Yea or use another provider like codeberg
Personally I'd never use codeberg. Their FAQ on licensing [0] is basically everything that anyone who supports free software should abhor - it's "we might allow you to do what you want to".
[0] https://docs.codeberg.org/getting-started/faq/#how-about-pri...
Re: An update on GitHub availability
#139I wonder if this mess has anything to do with talent loss resulting from layoffs after the pandemic
Re: An update on GitHub availability
#140I know that I'm simplifying (probably too much), but it seems like things were fine when GitHub was still a Ruby on Rails monolith and all the rigmarole with microservices etc. only made things worse.
This sounds more like a belief, based on little more than "correlation is causation", than analysis that controls for macro-trends backed by evidence.
It is, but everyone is entitled to beliefs. Anecdotally, I feel the same way. Everywhere I’ve been, there has always been a legacy monolith that was stable as a rock, with dozens of new microservices scattered around it in an attempt to exit the monolith. The microservices have never once been stable. People fail to take the most basic things into consideration, like “you can’t have Consistency and Availability when everything is a network call.”
I’m sure survivor bias is at play here, but when I look through the older code bases - especially the data model - it’s an entirely different world than the newer stuff, and it’s clear which of the two was written by people who understand systems.