Top
Best
New

Posted by salkahfi 3 hours ago

An Update on GitHub Availability(github.blog)
123 points | 121 commentspage 2
BlackFingolfin 2 hours ago|
GitHub stability has been bad for me. And recently even the data they show me in the web has been unreliably.

Since yesterday, me and several colleagues noticed that the pull request lists on the website are incomplete, across many repositories. For example, on https://github.com/gap-system/gap/pulls it says "Pull requests 78" in the "tab list", but the PR list view reports "35 open" (the number 78 is correct, and confirmed by e.g. `gh pr list`)

And that despite <https://www.githubstatus.com> reporting "all systems operational".

matharmin 48 minutes ago||
In many of my projects don't show any closed pull requests for the last 6 days. The CLI can list them, but anything going through search shows nothing.

Their support acknowledged the issue, but has been silent since then, and the status page still shows nothing other than the potentially-related issue on the 27th. It looks like it has been resolved on some repositories in the meantime, but I still have the issue across multiple orgs and repositories.

https://github.com/orgs/community/discussions/193388

embedding-shape 2 hours ago||
> For example, on https://github.com/gap-system/gap/pulls it says "Pull requests 78" in the "tab list", but the PR list view reports "35 open" (the number 78 is correct, and confirmed by e.g. `gh pr list`)

Surely a scaling hack where they use "estimation" queries that return "kind of right" results instead of 100% correct data, as it's less load on the infrastructure. Not necessarily a bug as much a shit choice from product perspective.

BlackFingolfin 1 hour ago||
If the numbers were all that is wrong, that'd be OK. But it fails to list all data -- so the only way to navigate to the missing PRs is to know their number, and manually inserting the right URL (or to go to another PR, and then edit the URL in the navigation).

Sorry, but I don't think there is any way this can be classified as "not actually a bug"

pluc 3 hours ago||
There are no words that Microsoft can use that would make me trust Microsoft.
s_ting765 2 hours ago||
> Vladimir Fedorov is GitHub's Chief Technology Officer .... He currently serves on the board of Codepath.org, an organization dedicated to reprogramming higher education to create the first AI-native generation of engineers, CTOs, and founders.

I think I found the issue.

steve1977 2 hours ago||
I 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.
remus 2 hours ago||
Unless everything else stays the same (underlying traffic etc.) then you can't really compare. Could be that you hit some fundamental scaling limit with the old design and it completely falls over after a certain scale.
steve1977 1 hour ago||
Oh as said I'm pretty sure things are more complex. It's just funny in a way that all these technologies that are usually being sold as "enablers for scale" don't seem to do their job very well.
tankenmate 2 hours ago||
This sounds more like a belief, based on little more than "correlation is causation", than analysis that controls for macro-trends backed by evidence.
sgarland 1 hour ago|||
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.

embedding-shape 2 hours ago|||
GitHub been oscillating between long phases of "Never any new features but rock-solid and no downtime" and "New features every week but also unicorns (used to be the "service unavailable page") every week" for as long as I can remember. Seems they're on some interval switching between the two.
otar 2 hours ago||
I had to postpone a call with developers (in 2 different countries) because I didn't had access to the issues board, which is a single source of truth for us.

I understand the rapid growth (because of AI agents), but if such critical software service becomes unstable then it's time to migrate? Thinking about self-hosting GitLab.

embedding-shape 2 hours ago|
> but if such critical software service becomes unstable then it's time to migrate?

Right way to think about this:

> If things we need/see as critical for our work are hosted on a platform with really bad reliability, it's time for us to migrate

My internet connection at home is really shit, and almost every week there is a multi-hour downtime for some reason, not to mention when La Liga games are on TV anything using Cloudflare is unavailable, so I've had to spend extra energy and time to setup things in a way so I can still work whenever this happens.

sltr 2 hours ago||
One thing is clear: an LLM wrote this.
throwatdem12311 2 hours ago||
> The main driver is a rapid change in how software is being built.

Leopard, meet face.

Too little too late, yesterday was the straw that broke the camel’s back for us and we’ve started a migration to a self-hosted GitLab.

jftuga 2 hours ago||
Some interesting tid bits:

* we had to resolve a variety of bottlenecks that appeared faster than expected from moving webhooks to a different backend (out of MySQL)

* * redesigning user session cache to redoing authentication and authorization flows to substantially reduce database load.

* we accelerated parts of migrating performance or scale sensitive code out of Ruby monolith into Go.

I'd like to know what database backend they migrated to. I was also surprised to read that the migration from Ruby to a more performant language had not already been completed. I assume this is because it a large code base with many moving parts, etc.

mohsen1 2 hours ago|
Another interesting bit: they are hitting performance issues due to the rise of monorepos. GitHub and frankly Git were not designed for monorepos
ghthor 1 hour ago||
Yet the Linux kernel is a monorepo
eolgun 2 hours ago||
The 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.

jcattle 3 hours ago|
When there's a gold rush invest in checks notes jewellery makers?
More comments...