Live data from Hacker News

An update on GitHub availability

github.blog

61–70 of 266 posts

Re: An update on GitHub availability

#61
post #53

This latest incident was the nail in the coffin for me. I've been on GitHub since 2012 but I'm feeling the pull to migrate out to Gitea/Forgejo. Has anybody done this recently? How'd it go?

When one of the incident they write about here happened, I wrote about my experience moving from GitHub to Forgejo which I happened to complete just the night before that happened: https://news.ycombinator.com/item?id=47878192 (lots of other people sharing their experience as replies too)

I was thinking of maybe doing a proper write up about how to host your own Forgejo + Action runners on Linux, Windows and macOS, not sure if there is enough interest. What would people for sure want to know in a guide/explanation of this?

Re: An update on GitHub availability

#62
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?

Re: An update on GitHub availability

#63
post #12

> we started working on path to multi cloud. Is this microsoft stating that they aren't able to get acceptable reliability from Azure? (I mean, I think a lot of us have heard that, but it's interesting to hear it from microsoft themselves).

I think this is more tailored towards enterprise clients that lose money when Github is down, that would probably help with retention.

Yeah that's a top tier enterprise plan feature if I have ever seen ut

Re: An update on GitHub availability

#64

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

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-optimization/th...

Re: An update on GitHub availability

#65

> we started working on path to multi cloud. Is this microsoft stating that they aren't able to get acceptable reliability from Azure? (I mean, I think a lot of us have heard that, but it's interesting to hear it from microsoft themselves).

Seems pretty sensible to not rely on a single provider for their large complex system?

Man, you should have been there 6 months ago when they decided to start tearing down GitHub's own data centers and move everything exclusively to Azure. Seems they themselves realized this after they started moving, but imagine if you could have helped them realize this before they even started :)

Re: An update on GitHub availability

#66
I can not figure out what on Earth they've done with these graphs, it almost seems like these are an artists impression of a graph.

Looking at the commit graph: Why do commits have big steps followed by slow rolloffs? Why do the steps not happen at uniform points Why do larger steps sometimes have less of a slope than smaller steps but not all the time?

Then looking at the other graphs there's completely different effects going on.

Re: An update on GitHub availability

#67
post #18

I'm biased (founder of tangled.org), but the future really should be federated forges. Host repositories on sovereign infra with global identity + federated "metadata" (issues, pulls, etc.). Global indices for this should be trivial to spin up so availability is never a concern (we're working towards this!).

I've never heard of this before, going to sign up and check it out!

Re: An update on GitHub availability

#68

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.

This sounds more like a belief, based on little more than "correlation is causation", than analysis that controls for macro-trends backed by evidence.

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.

Re: An update on GitHub availability

#69
so 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.

Re: An update on GitHub availability

#70
post #36
post #13

It's kind of hard to read this with a straight face. The unlabelled graph with big numbers on top, the priorities that don't match with what we're experiencing, and a list of things that they're doing without a real acknowledgement of the _dire_ uptime over the last 12 months....

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 2026, and these issues have been going on for a lot longer than that. GHA has been borderline unusable for a year at this point, if not longer.

> But given the rest of the content, I think that is safe to assume.

The rest of the content is "we're working on it", and "here's two outages in the last 14 days, one of which caused actual data loss"

Post reply on HN