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 message to GitHub’s staff, CTO Vladimir Fedorov notes that GitHub is constrained on capacity in its Virginia data center. “It’s existential for us to keep up with the demands of AI and Copilot, which are changing how people use GitHub,” he writes.

https://thenewstack.io/github-will-prioritize-migrating-to-a...

So the currently delayed feature development is now gonna be further delayed, yet almost every week we see new features and changes, just the other day the single issues view was changed, as just one example. And it was "existential" 6 months ago yet they keep stumbling on the exact same issue today?

Even if they're focused exclusively on reliability and uptime, we get the experience that we have today, kind of incredible how a company with the resources of Microsoft seemingly are unable to stop continuously shot themselves in the foot. It's kind of impressive actually. As icing on the cake, they've decided to buy up all popular developer services then migrate them all to the same platform, great idea too.

• madeofpalk

  today at 12:18 PM

  This seems uncharitable. Priorities aren't exclusive, especially at scale across large engineering orgs like GitHub. It could be that these are the top level priorities, but teams or individuals who aren't able to contribute to these priorities will work on other things like new features.

  • voncheese

    today at 3:14 PM

    Agree that priorities aren't exclusive and there may be teams/individuals that aren't able to contribute if they stay in their current teams/roles

    Where it becomes questionable though is when enough progress isn't being made on the top priority (reliability). If Github is being true to their word, they need to be pulling people off of teams that are working on features to work on reliability so that top priority gets the resourcing it needs.

    Given the pace of improvement, and the cited example of moving to Azure from months ago, it's not super clear they are doing that. Also not clear that they aren't, maybe the move to Azure is just a more than 6mo project no matter how many people are on it.

  • embedding-shape

    today at 1:48 PM

    Ditto. I agree though, just because the priority is reliability, doesn't mean others can't work on features, especially features that might help with reliability, which I read was the motivation behind the new single-issue view, so that's my bad, might have been a bit much.

    I still think the rest of my point stands, especially the last one which is the move that has the biggest impact to the most of us developers.

• ncruces

  today at 12:17 PM

  > So the currently delayed feature development is now gonna be further delayed, yet almost every week we see new features and changes, just the other day the single issues view was changed, as just one example.

  They did that as a panic mode hack to mitigate performance: https://news.ycombinator.com/item?id=47912521

• giancarlostoro

  today at 3:23 PM

  If they had not added or changed any features to GitHub for the past 5 years, nobody would be upset, and yet, they keep changing it. It's a website that doesn't need to be reworked every five minutes. I assume the main development teams maintaining GitHubs codebase are ran by managers who cannot justify their jobs unless they deliver new features for the sake of delivering new features to keep their jobs going, and / or in the hopes of getting new people to join GH, when in reality the more they wind up breaking, the more the opposite becomes true.

  They severely nerfed their search, I'm not sure why every other major tech company (Google - Search and YouTube) keeps breaking search for everything when it was working fine previously.

  What's a bigger joke is Microsoft has Azure DevOps which looks like it might be abandoned? But then you also have GitHub... My least favorite thing about both is the ticketing system, I cannot believe that I'd ever utter the phrase "I miss Jira" when every Jira project I've ever been in had been so inconsistently setup, every, single, one.

• rwmj

  today at 12:22 PM

  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.

  • today at 2:25 PM

  • 0xy

    today at 1:17 PM

    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.

    • alper

      today at 2:03 PM

      This entire exercise if anything is a huge indictment of Azure.

      But that doesn't matter because the kind of person that buys Azure, just like the kind of person that buys MS Teams, is entirely driven by price and does not care about anything else.

      • panarky

        today at 4:26 PM

        > entirely driven by price

        I might buy that argument if Azure compensated for its awful availability and security with lower prices.

        But the kind of person who buys Azure is the kind of person who buys Windows and Teams, perfectly happy to pay a premium for all the extra abuse.

  • AntiUSAbah

    today at 2:58 PM

    I mean its Microsoft and its Azure. How much can go wrong clicking yourself a few/hundred non autoscaling normal VMs?

    There is so much workload running on Azure, i never heard of VMs go away.

    If Microsoft can source hardware for Azure, Microsoft can source hardware for Github.

    • dijit

      today at 3:24 PM

      there's a lot that can go wrong with a hypervisor, even including hiding hardware issues from the guest OS.

      We don't think about it because we've been quite spoiled with excellent virtual machine platforms (KVM, Xen and even VMWare).

      Those that have worked a lot with VirtualBox will be aware of this, it can be deeply unnerving that VM technology is the default way to deploy things after you've spent sufficient time with VirtualBox. (which: is very good for its original purpose, but not for reliability).

      The question is: Does Azure use something more like VirtualBox, or more like KVM?

      HyperV exhibits properties closer to VirtualBox.

    • ZoneZealot

      today at 3:16 PM

      I've had Windows Server VMs soft crash and hard crash on Azure. Some soft-lock and a restart via Azure gets them back. Some times the only fix has been to power off / deprovision - then power on again (i.e. a restart didn't fix it). It's not common, but I've encountered it multiple times. These are with operating systems that were created in Azure from their images.

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

• georgyo

  today at 11:13 AM

  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 exponent log graph. But given the rest of the content, I think that is safe to assume.

  Any company that experiences significantly more growth than they were planning for will have capacity issues.

  The priorities are most inline with that. The are way beyond the point that they can just add more hardware. They need to make the backend more efficient, and all the stated goals are about helping there.

  • johndough

    today at 11:37 AM

    > You don't need to know the bottom left axis number.

    We very much do. The graph suggests an insane growth in PRs from almost zero to 90M. Now compare this misleading graph with this much clearer one, which shows that the growth over the last three years has been less than 80%: https://github.blog/wp-content/uploads/2025/10/octoverse-202...

    • today at 2:08 PM

    • SkiFire13

      today at 11:46 AM

      That link shows the number of PRs created to be less than 10M though.

      • johndough

        today at 11:58 AM

        Yes, to be honest, that graph could use some improvements as well. I should probably just link to the blog post with actual numbers: https://github.blog/news-insights/octoverse/octoverse-a-new-...

  • maccard

    today at 11:32 AM

    > 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"

    • today at 1:15 PM

• ncruces

  today at 11:04 AM

  More numbers: https://x.com/kdaigle/status/2040164759836778878

  What's the question here, you don't believe growth is currently exponential, or do you think it shouldn't be hard to scale, when 10x YoY is not enough?

  • OtherShrezzing

    today at 11:16 AM

    As a business user, our costs have gone up while service has gone down dramatically. Meanwhile our marginal cost to GitHub has hardly changed. Where our costs to them have increased, they mostly charge us per cpu minute, so obviously aren’t making any kind of loss on our account.

    I’m sure they’re experiencing scaling issues across the platform, but it’s unacceptable for that to have a negative impact on us when we're sending them $250/dev/yr for (what is in all honesty) hosting a bunch of static text files.

    • ncruces

      today at 11:39 AM

      I understand that, and maybe GitHub became a bad deal because of that.

      But if anything, their post and your reply are precisely an endorsement of usage based billing.

      The bit that's growing 13x YoY (and which they expect will easily blow past that) is unmetered - commits. The bit that is metered (for some, not all folks) - action minutes, grew only 2x YoY.

      GitHub was not built to limit the number of commits, checkouts, forks, issues, PRs, etc - nor do we want them to - but that's what's growing ridiculously as people unleash hordes of busy beaver agents on GitHub, because their either free or unlimited.

      Where there are limits - or usage based billing - people add guardrails and find optimizations.

      Because for all the talk, agents don't bring a 10x value increase; otherwise, they'd justify a 10x cost increase.

      Besides, other forges are having issues too. Even running your own. We have Anubis everywhere protecting them for a reason.

      • conartist6

        today at 4:30 PM

        That sounds bad. Paying users don't want huge and every-growing numbers of freeloaders reducing the return for each dollar they spend...

        That would only lead to further and further degradation of service until the paying customers were absolutely desperate to find a deal that didn't require them to lug around such a heavy ball and chain.

        It all made sense at the beginning when Github was free for OSS and OSS was thriving, but now these billions of commits are mostly incredibly low value. I'd bet the average commit now doesn't create 1/10th of the value the average commit did in, say, 2018

    • rdevilla

      today at 11:26 AM

      > we're sending them $250/dev/yr for (what is in all honesty) hosting a bunch of static text files.

      You know, you can just host your own code forge. Or you can just drop gitolite on a server. Or pull directly from each others' dev machines on a LAN.

      GitHub is not git.

    • tracker1

      today at 2:11 PM

      I'm curious how Azure DevOps reliability has been for comparison. My current job is managing stories in DevOps with SCC in GitHub ent. While I like Github slightly more, have been curious about the decision.

    • graemep

      today at 1:34 PM

      In that case, why are you using them at all?

    • dist-epoch

      today at 11:27 AM

      > we're sending them $250/dev/yr for (what is in all honesty) hosting a bunch of static text files.

      so start a GitHub competitor which bills $50/dev/yr for solving this easy problem and make a lot of money?

  • maccard

    today at 11:35 AM

    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 says is "we hear you're having issues".

    • ncruces

      today at 11:51 AM

      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 matter what's the y-axis baseline, unless we really think growth was huge in 2020, then cratered to zero by 2023, now back to the previous normal.

      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.

      You can already see people complaining loudly where they instead of "we'll do better" decided to limit usage.

      • maccard

        today at 12:27 PM

        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).

• PunchyHamster

  today at 2:07 PM

  You mean since GH acquisition 6 years ago https://damrnelson.github.io/github-historical-uptime/

• ramon156

  today at 11:01 AM

  "We hear you" in ~300 words, basically.

• ferguess_k

  today at 11:12 AM

  You can do the same with so many clients.

> 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).

• zamalek

  today at 4:08 PM

  There was somewhat recently a post here about how priorities, pressure, and management subverted Dave Cutler's vision for Azure (which was to have near zero human involvement) - my Google fu isn't strong enough to find it. Supposedly, someone running over or opening a serial to a rack/VM is now typical operational procedure.

  • ok_dad

    today at 4:36 PM

    This one?

    https://isolveproblems.substack.com/p/how-microsoft-vaporize...

  • pbronez

    today at 4:46 PM

    perhaps https://isolveproblems.substack.com/p/how-microsoft-vaporize... ?

• derwiki

  today at 10:52 AM

  It’s pretty damning. But as someone who has used Azure, I buy it.

  • everfrustrated

    today at 11:45 AM

    Pretty damming that two Microsoft subsidiaries - GitHub and LinkedIn - either shelved their forced migration to Azure or are looking at non-Azure options.

• cbg0

  today at 10:54 AM

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

  • bombcar

    today at 11:24 AM

    You’d think they could have had the existing GitHub on whatever continue as is (maybe for paying customers) while all the AI new inrush goes to the Azure setup.

  • jofzar

    today at 11:30 AM

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

• youwangd

  today at 3:46 PM

  Show HN timing matters more than people think. Monday-Thursday, 9-11am Pacific, is when the front page has the most engaged readers. Weekend posts get less competition but also less engagement.

• jasoncartwright

  today at 10:53 AM

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

  • embedding-shape

    today at 11:30 AM

    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 :)

    • nextaccountic

      today at 12:11 PM

      Made me think. Why not convert Github datacenters into Azure datacenters that have Github as their sole customer?

      Then it's up to Azure how they will manage this

      • hobofan

        today at 2:45 PM

        That sounds like the worst of both worlds? The Azure devision that can't even reliably can't provide decent infrastructure products based on their own data center trying to do the same one a bespoke data center.

    • benterix

      today at 11:55 AM

      > Seems they themselves realized this after they started moving

      I guess most people at Github knew exactly it makes no sense but they didn't really have a choice. Maybe some voiced their statement, got "we hear you" in response and were told to proceed anyway.

      • embedding-shape

        today at 11:59 AM

        Yeah, I don't know how it went down, but I also know exactly how it went down:

        Microsoft Execs: Everyone needs to move to Azure!

        GitHub developers: But Azure is not gonna be able to handle our load, we literally have our own data centers!

        Microsoft Execs: Sure, but you're Microsoft now, please publish blog post about how in half a year you'll be 100% on Azure.

        Few months later...

        GitHub Developer: We've tried our best, users are leaving in droves and Azure can't keep up!

        Microsoft Execs: Ok fine, you can use something else too, but only if you mainly use Azure and continue publishing blog posts about how great Azure is.

        • alper

          today at 2:05 PM

          Azure is the MS Teams of clouds.

  • cyanydeez

    today at 10:58 AM

    This isn't a mom and pop shop. They have locations all over the world: https://datacenters.microsoft.com/

    There's no intrinsic reason they should be vulnerable to themselves.

    • farfatched

      today at 11:24 AM

      +1. Multi-cloud is typically done for vendor independence.

      But Github don't have that rationale.

    • jasoncartwright

      today at 11:06 AM

      That website (for me) uses Cloudflare via WPEngine, which also isn't Azure

  • mijoharas

    today at 10:56 AM

    I mean, amazon (shopping, along with prime video e.t.c.) runs on AWS.

    • PunchyHamster

      today at 2:08 PM

      It was more "we built AWS to run our stuff and figured out we can sell it too".

      While Azure feels like Temu clone of Cloud

    • ksimukka

      today at 11:34 AM

      When I was at AWS, retail was not yet running on AWS. Has that changed?

      Prime video does use some AWS services, but live and on-demand are two entirely different beasts.

      • mijoharas

        today at 12:03 PM

        Really? I thought retail was. It's been almost a decade since I worked at prime video but I think everything was running on AWS. (Some things didn't use brazil etc, but I think all the servers etc. were on AWS)

        • malfist

          today at 12:20 PM

          It's a distinction without a difference. All new development is nAWS (native AWS) legacy is mAWS (not sure about the acronym) which is still AWS under the hood and is mostly just a pool of EC2 instances with preconfigured networks. Nothing made in the last five or six years is on maws, and amazon is a micro service shop so things are always being built new. If you joined today there's a good chance you'd join a team without any maws infra

          • cmckn

            today at 1:56 PM

            MAWS is “Move to AWS”, the name of the internal campaign to get legacy services into a somewhat-retrofitted AWS environment. It was a single VPC at one point.

            • malfist

              today at 3:42 PM

              I just finished a nearly five year stint at amazon and didn't realize there was pre-maws stuff still around. Never encountered any of it. I was like two months from my yellow badge but, uh, life is really better outside amazon.

    • jasoncartwright

      today at 10:58 AM

      Prime video uses a non-AWS CDN when I watch football on it here in the UK

      • farfatched

        today at 11:28 AM

        The BBC were unable to find a single CDN that could serve the UK during its peak football matches. https://www.bbc.co.uk/webarchive/https%3A%2F%2Fwww.bbc.co.uk...

• today at 12:05 PM

• jansan

  today at 11:36 AM

  The entire concept of multi cloud is amusing if you think what cloud originally was supposed to be. They could call them meta clouds (might infringe trademarks), and with the current growth trajectory of AI generated code eventually multi-meta-clouds, renamed to beyond-clouds, and then multi-beyond-clounds. I see no limits.

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

  today at 1:03 PM

  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

  • tracker1

    today at 2:21 PM

    I'm not able to see the current release-please PR and the last one broke during release creation so aborted the deploy. Hoping today goes better, but limited expectations after yesterday and may be deploying manualy.

• vinc

  today at 2:13 PM

  I noticed the same thing and indeed the status page is not reporting the issue. I could find the missing PRs by browsing the branches page.

• embedding-shape

  today at 11:42 AM

  > 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

    today at 12:08 PM

    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"

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.

• jospeh554

  today at 1:55 PM

  It's because they are your standard PowerPoint graph that just shows "thing goes up" rather than actual data, or the meaning of the data.

  • arnitdo

    today at 4:35 PM

    They seem to be the result of an image-gen model to me

    If this is the unvetted and unbased information they are putting out in public facing-blogs, only the stars would know what data is being "presented" in their boardrooms

Glad that they released some data about new repo/issues/commits over the last years. It confirms what everyone else already believed from the outside: agents are putting a lot of extra, sudden pressure on GitHub. It's like a startup that is growing exponentially, with the difference that they already have a large user base to serve - and that keeps them in the bullseye - and probably a not-so-fast-moving organization when it comes down to changes. On the other side of the coin, they also have a lot of talent, infra and money a startup might not have yet.

• maccard

  today at 10:55 AM

  What data is that? There's an unlabelled graph and a number at the current peak.

  • ncruces

    today at 11:00 AM

    Some previous numbers: https://x.com/kdaigle/status/2040164759836778878

    • maccard

      today at 11:28 AM

      This is the data that should be in the blog post. Thanks for sharing.

  • today at 11:45 AM

  • darkwater

    today at 2:18 PM

    IMO it transmits the magnitude of the impact pretty well.

What are we doing?

Stop subsidizing tokens now that we extracted enough training data from you and we have enough agentic junkies business to keep the flywheel going up and cut on the loss leaders. [0]

[0] https://news.ycombinator.com/item?id=47923357

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?

• jmbwell

  today at 12:20 PM

  I understood it to mean, GitHub is being crushed by LLM/AI/Agentic code review and submission, not GitHub’s code itself

  What I’m not seeing here but I am seeing with the Linux kernel is, most of the automatically submitted code is irrelevant or not useful

  (Maybe that’s what you were getting at, apologies)

• whstl

  today at 11:32 AM

  I for one believe Microsoft when they say this code is going to Github... to die.

  Half of my friends is vibe-coding something but they can barely get the rest of the group chat to use it once.

  In companies, I see people vibe-coding "miracle apps" that fall under the smallest amount of scrutiny.

  Basically people are doing the same developers do when they say "I can do this in a weekend", which is getting a prototype sort of running and then immediately losing energy (or in this case lacking ability) to push it forward.

  • jansan

    today at 11:39 AM

    > Half of my friends is vibe-coding something but they can barely get the rest of the group chat to use it once.

    Some people I know can't even explain what they are trying to create.

• yakattak

  today at 1:13 PM

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

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

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!).

• PunchyHamster

  today at 2:14 PM

  It's cute idea but most people don't want to host their own stuff.

  And if they are using 3rd parties to host their stuff, inevitable 1-3 big players will show up offering that as a service.

  And even if you do host your own stuff to avoid availability problems, the big actors can still fail just like GH and you can't do shit coz your dependencies need it.

  So the solution is same as it is now, proxy or mirror everything you use

  • icy

    today at 3:45 PM

    Yeah that's fine, we offer first-party hosting for free forever.

• ArcHound

  today at 11:04 AM

  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.

  • nibbleyou

    today at 11:13 AM

    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.

    • pabs3

      today at 12:24 PM

      git itself can push to multiple URLs btw:

      https://stackoverflow.com/questions/849308/how-can-i-pull-pu...

  • embedding-shape

    today at 11:22 AM

    There are distributed forges? Yes, git is distributed, but often everything around it isn't. The case parent is trying to make, is that the rest ("federated forges") should also be distributed, not just git.

    • ArcHound

      today at 11:35 AM

      Ok, gotcha. So there's a demand for the additional features that are not bundled within git to be federated somehow.

      I'd say we have emails, mailing lists and bug trackers. Or maybe: what is the missing killer feature that needs federation?

      • embedding-shape

        today at 11:37 AM

        > what is the missing killer feature that needs federation?

        Issues, pull requests, collaboration/permissions/access, "staring"/"favoriting", etc.

        I think ultimately the goal is that people can run their own forges, yet still collaborate on repositories hosted in other forges, leveraging your existing authentication so you no longer need to sign up individually for each forge.

• ljm

  today at 11:59 AM

  I would love if it coding agents didn't default to GitHub for their deep VCS integration.

  If I could get the same bells and whistles by wiring up another forge, so long as it offered a decent API and/or sent events over a webhook, I'd have everything self-hosted.

  The agents would need to expose an interface on their own end but as long as you implemented it with a plugin, it'd take the dependency of GitHub and you could use MCP or skills for the rest of it.

  • icy

    today at 12:03 PM

    The neat thing about Tangled is it's built on an open protocol (https://atproto.com)—this allows us to effectively build an API-free system since all data on Tangled can effectively be ingested via the AT Protocol firehose.

    Which is to say, this is perfect for agents given they don't need any bespoke SDK from us: simply write Tangled records for issues, pulls, whatever to your PDS and it'll show up on Tangled. We plan to start working on some exemplar agents first-party that would 1. enhance Tangled itself, 2. showcase cool things you can do with an open data firehose.

• ramon156

  today at 11:02 AM

  Love the idea, would replace the LLM generated content ony our site, though.

  I recently migrated to codeberg because I'm okay with self-hosting big runners, while using codeberg's available runners for smaller cron-based things (they even have lazy runners for this).

  • icy

    today at 11:24 AM

    It’s… all hand written? We just sound “professional”.

• sikozu

  today at 11:32 AM

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

  • icy

    today at 11:40 AM

    Thanks! If you need anything, email me anirudh@!

• beernet

  today at 11:05 AM

  What is "sovereign infra" exactly?

  • mathgeek

    today at 11:22 AM

    I know it's just marketing speak, but the term made me think of the scenes in the Matrix where what's left of humanity (ignoring all the cyclical lore that was added on top of it) has to make sure the machines can't remote in to any of their tech.

  • tfrancisl

    today at 11:09 AM

    No less than self hosted, imo. If youre on some cloud it doesnt really matter that you pay them absurd amounts of money, you arent sovereign.

    • beernet

      today at 1:27 PM

      So if a company self hosts their physical infrastructure which will burn down once a fire sets in, they are more "sovereign" than a company running on a redundant cloud? I definitely would not want to be "sovereign" then.

      Point is: This discussion is much more multi-dimensional than some suggest.

    • embedding-shape

      today at 11:22 AM

      So literally a computer at home/in the office, as with anything else you don't really "own" the infrastructure? Or is this just about "cloud"?

      • icy

        today at 11:37 AM

        Yeah sorry it's marketing BS speak for self-hosted or just infra that you control. It could be a VPS, it could be a Raspberry Pi at home. Your repos live on your servers. (And we support this on Tangled today!)

        • embedding-shape

          today at 11:38 AM

          > just infra that you control

          But a VPS isn't actually infrastructure you control, you essentially have as much control over it as "cloud", so I don't think that'd be counted as "sovereign", would it?

          • icy

            today at 11:46 AM

            Perhaps, but it's still better than nothing!

• iso1631

  today at 1:38 PM

  > the future really should be federated

  The internet should not be centralised, but you can't make a billion dollar company without capturing the world and selling your company to a trillion dollar company

> Our priorities are clear: availability first, then capacity, then new features.

No mention of Copilot/slopiffication. Probably an intentional omission as Microsoft only has one true priority across all of its products.

With this prioritization Github IPv6 support is gonna happen the next decade.

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

  today at 11:08 AM

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

  • ghthor

    today at 12:50 PM

    Yet the Linux kernel is a monorepo

    • guipsp

      today at 4:32 PM

      The Linux kernel is pretty small

    • mohsen1

      today at 3:20 PM

      Try google3

openai, anthropic, google and a plethora of chinese models all end up pushing code into github. you can discuss whether gpt 5.5 is better than opus 4.7, but for github it doesn't matter: they'll be receiving the code no matter which llm spits it out.

amazing on one hand, quite scary on the other for github and all other forges if this continues and there is no reason why it wouldn't.

• graemep

  today at 1:41 PM

  Simple solution: charge all users. Charge more for higher usage.

  • gattr

    today at 2:44 PM

    And/or provide a baseline free tier, corresponding to how much a typical human user would at most push/clone etc. They have pre-LLM statistics on that.

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.

• 2ndorderthought

  today at 11:39 AM

  AI is the new DNS when it comes to service failure.

  • cindyllm

    today at 11:49 AM

    [dead]

LLMs have helped us invent websites that only work sometimes. We're truly living in the future.

Two 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

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?

• embedding-shape

  today at 11:29 AM

  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?

• today at 11:28 AM

• sltr

  today at 11:35 AM

  I moved over back when GitHub was planning to charge per minute to use my own runner. It was easy with Claude, the gh API, and forgejo web API. I even set up daily backups to my S3 clone of choice.

  The only repos I left on GitHub are forks and one with a bit of public engagement.

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.

When there's a gold rush invest in checks notes jewellery makers?

There are no words that Microsoft can use that would make me trust Microsoft.

> The main driver is a rapid change in how software is being built. Since the second half of December 2025, agentic development workflows have accelerated sharply.

GitHub instability has started way before that. I understand it’s too much to ask of a trillion-dollar corporation to consider the impact of their own actions, but perhaps they should’ve thought of that before forcing LLM development down everyone’s throats.

• mathgeek

  today at 11:19 AM

  While they contributed, they were still following the market trend anyway. If they weren't letting folks use it directly, other companies would have (and are).

  • latexr

    today at 11:22 AM

    > they were still following the market trend anyway.

    They started the trend with Copilot.

    > If they weren't letting folks use it directly

    There is a chasm of difference between “letting you use it” and “forcing it down your throat”. Microsoft is doing the latter, not the former. Copilot is annoyingly present by default at every step on GitHub.

> posts graphs without way to determine scale of y axis

Now that’s the kind of excellence I expect from the GitHub engineering team

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

  today at 11:41 AM

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

I wonder if they’ll end the free lunch we’ve been having since the MS takeover. There’s been a deluge of spam and crapware projects due to the LLM wave which is visible in that graph. Can’t see them sustaining being a public dustbin for low value projects forever.

• sbarre

  today at 11:24 AM

  I could see them expiring/archiving/deleting inactive projects after some time.

  I feel like this would have negative impacts (lots of interesting historical archives on Github) but maybe if a project hasn't been touched, or cloned, in some time, it just gets deleted with some notice.

  • rmunn

    today at 4:04 PM

    Thing is, projects that don't get touched for months and months are the least costly. Disk space is cheap; what's costly is compute time to process new commits, new/updated/closed issues, new/reviewed/merged PRs, and so on. Inactive projects just sit there taking up disk space but basically zero compute time. So it would make no sense at all for them to delete old, inactive projects. (Which doesn't mean they won't do it: they might have hidden costs I'm unaware of, or they might make stupid decisions. People do make stupid decisions sometimes).

  • today at 2:24 PM

The availability of GitHub is still at 0% - it can't be reached over IPv6.

> While we were already in progress of migrating out of our smaller custom data centers into public cloud, we started working on path to multi cloud. This longer-term measure is necessary to achieve the level of resilience, low latency, and flexibility that will be needed in the future.

Wild

The bit nobody covers in these write-ups: small teams without dual-cloud failover budget. Last big GitHub outage cost me a deploy day. Not catastrophic but the kind of thing you don't budget for when GitHub is your single source of truth.

Status page is also still doing that thing where every component is green but in practice clone is hanging, push is timing out, actions are stuck. Per-service uptime is a managed number. The user-experience number is the one that matters and it's not in the post-mortem.

• AlexeyBelov

  today at 3:01 PM

  No LLM comments.

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

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

  today at 11:37 AM

  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

    today at 11:59 AM

    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

  today at 11:26 AM

  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

    today at 12:41 PM

    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

    today at 11:32 AM

    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.

So I gather that nobody is working on a search that stays on the current branch?

LLMs and vibe coding ruining it for the rest of us.

Github has been having availability issues for years now.

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

• pointlessone

  today at 12:45 PM

  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.

fwiw, I've had good luck scaling git, specially doing clones, in the HTTP layer, using Varnish. this was CI bringing Github Enterprise to it's knees.

Personally, I’m sympathetic. We know that GitHub did a huge amount of work over the last decade to make Git scale, which has benefited us all. These new scaling challenges are real challenges, 30x growth would be a nightmare for any system that was already pushing the limits of what was possible, I think we are being far too hard on GitHub, they deserve a little grace.

• remus

  today at 11:47 AM

  For all the negatives about github I agree. They offer a lot of free stuff, and LLMs seem likely to put massively increase their costs with no guarantee they'll be making money off it. I can't think of many (any?) large businesses which could scale up to meet so much new demand without some significant growing pains along the way.

• someone_eu

  today at 11:11 AM

  GitHub's scaling issues are caused by their own vendor-lock approach and monopoly. Yes, of course _their_ goal is to be even bigger and even more all-consuming, so _they_ have to deal with the scale. Why a user would be sympathetic to that?

  The user (and not a big tech monopoly) answer to scaling issues is almost always to stop scaling and start federating and interoperating.

blame 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.

> Our priorities are clear: availability first

That's a delayed April fool's right?

• embedding-shape

  today at 11:46 AM

  No, just a 6 month old memo that was first opened today, as they said literally the same 6 months ago.

Nice, they have availability numbers now on their status page, but they aren't aggregating.

If you multiply all current numbers together (as of Apr 28), you find out that GitHub has a 97.26% uptime.

One ... single ... 9.

They can do better.

• embedding-shape

  today at 12:06 PM

  Kind of unfair though, do the same for any platform with multiple services and you'd probably get <99% for most of them.

  > you find out that GitHub has a 97.26% uptime

  Calculating that to "Downtime per day" you get ~40 minutes of downtime per day, almost a week per year. Crazy stuff for something essential like this.

Microsoft has been an abysmal steward of Github - the few nice features it has over self-hosting just aren't worth losing an hour or more of CI/CD downtime during daylight hours every week.

Yesterday was the last straw for me - I've begun migrating my personal private projects and my contracting firm's projects off of github.

Availability is priority? Does not seem like it is https://mrshu.github.io/github-statuses/

One thing is clear: an LLM wrote this.

As 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.

• today at 12:15 PM

• tosti

  today at 1:11 PM

  Sorry to ask but... Do you have any idea how git works???

• 2ndorderthought

  today at 11:37 AM

  Yea or use another provider like codeberg

  • maccard

    today at 12:37 PM

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

  • imrozim

    today at 11:41 AM

    True but switching is not that easy when all your ci pipelines and integration on in GitHub.

    • embedding-shape

      today at 11:45 AM

      I don't think it's 100% compatible, but Gitea's/Forgejo's (which Codeberg runs on) own Action implementation is pretty much the same as GitHub Actions, with minor differences.

      • imrozim

        today at 1:57 PM

        Good to know might actually try it for one project 1 st before switching

So they haven't even finished migrating from their datacenters to Azure and have now started a project to add another cloud provider ("multi cloud")? Madness.

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 that, surely you can incrementally deploy changes across those many shards to avoid most big outages?

are there big conceptual serialisations that I've missed? is it just not well factored? was the move to Azure just a catastrophically bad idea? some other thing?

• fontain

  today at 11:49 AM

  Almost every high volume service on the internet is write a little, read a lot, and when there are writes, they're relatively small, a few bytes into a database that can fan out. GitHub is very different: constant writes, large files, it is under far more pressure than the systems the rest of us build. And then, as the article says, vibecoding happens, and suddenly they're receiving 30x the volume of expensive operations. GitHub are responsible for many of the performance improvements made to Git over the years, Git scales today because of work GitHub did, but that work was never intended to scale to volume of today.

  Even as recently as 18 months ago, Lovable appeared, seemingly overnight, and caused huge problems for GitHub because they were creating repositories on GitHub for every single Lovable project, offloading the very high cost onto GitHub, hundreds of thousands of repositories. A couple of years before that, Homebrew used GitHub as a de facto CDN and that was a huge problem, too.

  Nowadays it is easy to imagine how we can scale out a service like Twitter or YouTube or Facebook because everything has been done before, but that's not true of Git, Git hasn't ever scaled like this before, there are very few examples of service with GitHub's characteristics.

  https://lovable.dev/blog/incident-github-outage

  https://news.ycombinator.com/item?id=42659111

• dist-epoch

  today at 11:30 AM

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

  • bananapub

    today at 11:34 AM

    I'm asking about the infrastructure, obviously they chose for some reason to make my computer fans turn on to show some red and green lines on a text file.

    • dist-epoch

      today at 11:49 AM

      terrible frontend architecture suggests poor engineering culture which typically spreads to all teams, including the infrastructure team

AS IF THEY POST THIS WHILE THEIR SEARCH IS BROKEN, what a circus

Regarding their image with stats (https://github.blog/wp-content/uploads/2026/04/record-accell...) - what exactly are the ranges on y-axes? I doubt they had close to 0 PRs merged in 2023 ;)

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

Load from paying customers vs. load from nonpaying users would be interesting to know. No doubt omitted deliberately.

Ruby catching strays

Good chuckle out of this post, it’s crazy that neither Atlassian (Bitbucket) or Gitlab are capturing value out of this same agentic coding boom. I wish github was separately publicly traded outside of Microsoft.

Nowhere to get exposure to this

[dead]

I’m pretty sure my Forgejo instance on a Raspberry Pi is outperforming GitHub reliability. It’s faster that’s for sure.

I 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 until we've got availability sorted out!"

• madeofpalk

  today at 12:22 PM

  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.