Live data from Hacker News

An update on GitHub availability

github.blog

141–150 of 266 posts

Re: An update on GitHub availability

#141

I wonder if this mess has anything to do with talent loss resulting from layoffs after the pandemic

I’d guess it has much more to do with the extra load agentic ai generates. If we take the charts in the OP at face value, do you think gh suddenly exploded in popularity? At this point I think almost everyone who has any use for gh already has an account and use it as much as they ever would. But all the charts go to the moon. Gh obviously didn’t take into account that ai agents can generate a lot of activity they don’t have capacity for.

Re: An update on GitHub availability

#142
post #32
post #23

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 databa…

Another interesting bit: they are hitting performance issues due to the rise of monorepos. GitHub and frankly Git were not designed for monorepos

Yet the Linux kernel is a monorepo

Re: An update on GitHub availability

#143

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 co…

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

Re: An update on GitHub availability

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

I am surprised that Microsoft is allowed to use Go. How long will it be before a bean counter forces a rewrite to a Microsoft favored language?

Re: An update on GitHub availability

#147

Not enough attention is being put in the production/delivery mismatch. GitHub is claiming they require 30x scale due to the giant increase in repository creation, PRs, commits, etc. I have not seen a single product increase in features or quality as an end user, nor new significant products have come out in this period (other than the LLMs themselves). Where is all this code going?

To die. I’m sure that’s nothing new for GitHub, but now it can happen at scale.

Re: An update on GitHub availability

#148
post #70
post #36

Earlier 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…

> These are not the worst graphs in the world... Sure the bottom left axis is not labeled, but it still conveys the point correctly. No, they're completely useless. Using the "New repos per month" as an example, if the bottom left is 1m, then that's a 20x increase in 2 years which is a lot. If the bottom left is 19m, it's a 5% increase in 2 years which is nothing. The massive surge on their labelled X axis starts in…

[deleted]

Re: An update on GitHub availability

#149
post #132

Hah, 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.

Azure is easily the least reliable and least secure of the 3 hyperscalers, which is crazy because GCP was an also-ran underdog not that long ago.
Post reply on HN