> Errors in those services triggered a client-side retry loop that increased traffic during recovery
Symptomic of a wider trend to avoid showing the user any error at all costs, even if that means they sit watching a spinner for 7 hours.
> Delayed replies to a single internal endpoint triggered a latent retry bug in VS Code that amplified traffic by approximately 10x and caused delayed recovery for the Copilot Token Service.
The detailed root analysis tries to pass this off as a "bug". You can't seriously tell me client retry doesn't have a unit test which ensures the retry back off behaviour is functioning exactly as designed. In this case aggressively to try and hide problems if token service responses become flakey.
"You can't seriously tell me that the unhappy leg of the code path has no test coverage."
Sometimes I forget how ignorant HN can be of real world software development and the bar of corporate code quality, and then bangers like this remind me of it.
I cannot even begin to express how many times I've seen engineers working super hard to optimize happy-paths so that we turn 3 nines of availability into 4 nines but introduce unintended emergent behaviors in unhappy-paths that turn 1 nine into zero nines via thundering herds, retry storms, etc.
You have my empathy for this kind of sentiment. Personally this seems somewhat rare in practice. That being said I'm curious if anyone has anecdotes they can share about these kinds of things?
Configuring postgres to automatically failover instead of doing it manually. The automated system caused more downtime in a few months than manually doing it did for years before. All in the name of more automations and less downtime
It seems to me like you're saying nearly the opposite of them. You're saying "no matter what tests you have in place, it happens", while they're suggesting low standards and few tests.
Copilot probably wrote the code confidently and it was never looked at by a human then yolo’d out to meet the pointy haired bosses arbitrarily short timeline to then look good to his boss and so on
It’s been proven that VS Code has product managers who vibe code commits that get merged, including the co-authored with copilot bug. So there’s some problems there.
That was the final straw that stopped me using it.
I didn’t/don’t want the AI, I didn’t like the telemetry but it could be turned off but the cavalier disregard to just yeeting shit into a tool used by that many people no thanks.
I have been using Zed lately and quite liking it. I used Jetbrains for years, but it's gotten absurdly buggy lately so I probably won't renew it. I have also used vscode and I need to use it at work, and it's fine, but I prefer Zed (fewer bugs, faster, mainly).
I always advocate for the "boomer" editors when possible. It doesn't matter which one you choose. People can say what they want about them, but very little software survives almost 60 years. I sure as Hell hope VS Code doesn't.
At some point, esoteric UIs may have been needed in the 70s, but that ship has long sailed. I don't need to give myself carpal tunnel syndrome trying to quit vim. If anything, a lot of that is also a problem that continues to plague software to this day: devs who go "well if it works for me, it's good enough for anybody, and if you don't like it, you must not be a Real Developer!"
If you've only worked at a small-to-medium privately held company you'd assume every company ran that smoothly. "Too big to fail" makes sense once you've worked for a behemoth and not before.
I solve real problems at scale and the engineering practices I see on a daily basis are a clown show.
There's little to no basic understanding of networking, distributed systems, databases, etc. 99% of our engineers were hired from their college internships and never worked anywhere else. Industry hires to improve systems rarely last more than a year and it is almost never their fault.
We're in the next tier down from the biggest tech companies and what we do is hardly uncommon among our peers.
I should be shocked that 99% of engineers I deal with treat all resources as infinite bandwidth, 100% uptime, but I'm not. They NIH super hard and write tons of code for things that a docker container running nginx (or similar) would solve in 5 minutes. There's almost no useful testing and worse documentation.
I think a lot have mostly experienced working for tech companies and do not understand how different that is from working at some other kind of company (particularly something not technically sexy) doing tech (see last parenthetical).
I have never heard anyone ever utter the words, "Microsoft makes great products and services." They basically built an empire on brand recognition and vendor lock-in. Of course, a lot of their success was due to catching lightning in a bottle a few times at the right moments.
It is miraculous how they continue to fail upwards somehow. I suppose it's because they just vampirically sustain themselves by acquiring other companies and sucking them dry until they are a husk of what they once were -- like Github, Activision/Blizzard, LinkedIn, Skype, etc.. I remember when those companies used to actually produce good products and services.
That means nothing, especially with all the layoffs.
One thing that I learned over the years is never mystify "code quality". Maybe you can say a certain team/project produces high quality code, and maybe Google's overall quality is better than my company's (considering their bar of hiring), but you want to avoid generalizing that, especially at scale.
The average software engineer at a large company ships just enough code at good enough quality to earn a salary, nothing fancy about it.
Answer is, you do comprehensive unit testing irrespective of Microsoft or any other company doing it. Also, as the OP of your comment posted, you are over estimating the software quality of these big name corporate companies. It can’t be the bar against which you would want measure your own company standards.
A common pattern in highly available services is that sometimes you should retry immediately (because the node you hit is rolling/broken/overloaded, but the others aren't) and other times you should back off aggressively (because the service is degraded).
If your server indicates with 100% accuracy when to retry immediately vs backoff, AND if all your clients consume that information with 100% accuracy, things go great. But there are lots of situations where one or both of those breaks down.
Anyone who designs such a system should know to use an exponential backoff to avoid the thundering herd. Maybe copilot missed that while it was reviewing its own PR
Exponential backoff is the wrong answer in a highly available system in the typical case where (a) failure is expected and (b) you have nodes you are supposed to fail over to.
Your highly available system is probably somewhat important, otherwise you won’t have invested in making it HA.
While your premise holds for happy cases, when you do have a cascading series of outages, not using exponential backoff is just adding a self-inflicted DoS to when you do go down.
I don’t really follow your premise and can’t really articulate many cases for when you shouldn’t use exponential backoff. Maybe if you’re working at Jane St or something; or other circumstances where you can deploy immediate changes to the client; and you’re willing to trade ‘better p50 for worse outages’.
But in the case of shipped code that’s run on clients, I’ll continue exponentially backing off all the way, all the time, for everything.
When you have an outage, you should not retry at all. Exponential backoff is exactly how you get cascading outages. If service A fails a request to service B and decides to exponentially back off, now service A is holding open an end user request that will claim resources on service A. Fast forward ten minutes and the service B degradation has metastasized into a service A degradation. And even after service B has recovered, service A might still be dead.
To handle this correctly you need your RPC framework to accurately communicate retryable vs non-retryable failures to clients. Then service A knows service B is dead, does not retry, and proapgates the failure to clients. This is hard to do perfectly, but there's no alternative that works.
Try asking Opus or Fable that question. It'll give you a good answer on why microservice architectures work the way they do in order to keep user-facing latency acceptable and minimize downtime. It's a complicated enough topic that I don't feel like explaining it for free to you in a HN comment.
Why are you pretending this is a harder topic than it is and you have some secret insight. And you're a dick on top of it:
Yes, exponential backoffs alone are insufficient. Yes, adding jitter helps randomize the calls across a fleet and should be the default with exponential backoffs. Yes, both of these may be sufficient for most systems. Yes, you can dive more into circuit breakers and adaptive retries to limit thundering herd.
The right answer is for the RPC framework to accurately communicate "try again on another node" vs "don't try again, just hard fail".
When one end user request fans out to hundreds of backend requests (typical for microservices), you can't have each of those backend requests do its own exponential backoff. If they do it in parallel, they're a thundering herd, and if they do it in serial, the end user request will time out before you finish all the work, at which point you're doing a bunch of slow expensive work for no gain (and the enqueued slow expensive work will make your outage worse).
> because the node you hit is rolling/broken/overloaded, but the others aren't
Retries in such a situation should be handled internally with the client at most responsible for failing over with a circuit breaker to another zone. Having the client auto retry right away is not something that behaves well as shown here, even if in the happy path it happens to stimulate increased availability without actually investing in the proper architecture for it
> You can't seriously tell me client retry doesn't have a unit test which ensures the retry back off behaviour
That wouldn't be a unit test - that's more like an end-to-end or integration test.
Have you ever worked anywhere that had perfect test coverage? It just doesn't happen, nor is it possible unless you're building a calculator app or todo list.
My employer has 0% test coverage lol. I've begged and pleaded, but the claim is that "risk is low" and "that's what QA is for." Hell, I've complained to senior management about how there are senior devs that forgo backend validation. It's truly Hell in the trenches sometimes.
Some days, I would seriously rather work at Wendy's.
> You can't seriously tell me client retry doesn't have a unit test which ensures the retry back off behaviour
Not to join the parade, but what would a unit test that confirms a cycling behavior across all the instances in-flight even look like? I mean, besides "Not a unit test".
Maybe the retry logic was vibecoded instead of using an existing hardened library. After all, according to Twitter, nobody is looking at the code anymore.
A lot of retry libraries I’ve seen require the user to configure them. You can use a library with all the right settings, but if you configure it wrong, you are really no better off than if you hadn’t
Backend API rate limiting has to surely kick in and force you to wait x amount of time before you try again… Discords bot API actually sends you how long before you retry.
As a client you can hit a server as much and as often as you like. The only thing the server can do is return an error code or try to hold the socket open (which the client can then close on their own).
Except the other side of this is interrupting a service which would otherwise have succeeded: there's a lot of unattended or minimally attended processes where an interruption is just asking the user to do the only thing they were going to do anyway - retry it.
In GitHub's case this is especially relevant - the only reason to throw an error message at the user is the hope they - the human - give up and walk away (or you break all the CI/CD builds and the time it takes humans to hit "retry" gives you some breathing room).
For some context, in June they said commits "commits nearly doubled year over year, crossing 1.4 billion per month". Now, it has more than doubled that in just a few months.
Makes sense given the ubiquity of agentic coding. I made a joke to my coworker today that all we do is make sure AI agents can communicate with other AI agents.
Nixpkgs has 11k open PRs at the moment (a lot of them routine version bumps and such), so no. But then Nixpkgs isn’t a piece of software in the conventional sense: the monorepo does contain a few of those, but most of it is a giant collection of basically-independent build scripts.
Well either they can handle this load that Microsoft can't, or they can't. If Microsoft are going to continue to be unreliable in the absence of the rate limit then:
If alternatives can handle the load, those who would consider those alternatives if Microsoft opposed a rate limit are likely to move to them anyway.
If alternatives aren't able to manage, then user's aren't going to jump since those services won't actually provide more usage.
I was thinking the same thing at first: ideas to increase product limits on GitHub, to increase reliability given limited infra.
However, there are sharks in the water, and with the diminishing mean of user technical knowledge, the product actually needs to become even more free. GitHub likely needs even lower friction.
"All it takes" is the insanely heavy technical lift to support that. There is no other solution. All the C-Suite needs to do is foster an environment with well-thought through, and possibly over-funded engineering, at the edge of the art. That sounds like an amazing challenge.
I still remember when they decided to limit the number of private repos you could have as a free user. Kind of silly to me at the time, and even more so now!
Which will just increase the cries of "enshittification" and hasten the mass migration to the next free platform that surely, this time, won't ever go down.
We're small enough that we've been hosting our git infra for about a year now, I wonder how many other companies figured out they could make the trade. I've had a Github since a couple years after they started and I think they are going to become a Stack Overflow, albeit slower with MS at the helm. If Github is going to be 99% slop it's going to be really hard to use as a fun tool to show what you can do, what you've worked on, side projects, etc. I took github off my resume and I'm probably not going to relaunch my weblog if I end up job hunting, too much low-effort crap and people basically copying what a lot of us had been doing manually for years to really feel like it's anything other than a negative signal.
GH processes at the commit level for things (including actions) even though they're bundled in a push... it's relevant to the load on their infrastructure.
In what way? If I have multiple local commits pushed once I expect to see CI type actions to run once for the push rather than for ever commit in the push.
Probably? If you do 100 pushes instead, there is roughly zero additional data. At best you'd be comparing cache costs, which probably are lper for one large push, but there's a ton of calculation and CI that runs per commit regardless of other data being cached.
Why don’t you have your actions run on pr or push instead of on commit? Why would you even want that? I’ve never seen actions set up that way. If I push a branch with 100 commits then it’ll only run CI once. It’ll show the rest of the commits in the UI, sure, but that doesn’t mean that it’s the same performance impact. It could very well be 1 db transaction with multiple rows written instead of 100. I think you’re reducing this problem too much without knowing their architecture.
Github runs CI per PR push (obviously), and per main-branch commit (click on commit history in any project with CI, see a build result check mark on each one - that's true if you push a dozen commits too (I've done that)), in nearly all setups I've seen. I'm not sure how much of that is required vs default though.
With enough effort, you can rather obviously run CI per PR commit (it's a programmable system), but I've never seen aUI-integrated way to track the results, aside from browsing custom job names, which is very far from what I'd call "integrated" when compared to PR-level build markers. Similarly, I'm not aware of (but would not be surprised by) any way to disable per-main-branch commit builds, aside from initial pushes.
But I haven't poked around deeply in the settings, and business-account settings are rather different anyway so those might be wildly different / more flexible / more obtuse in exciting ways. Github is a very large and complicated product at this point, darn near anything could exist if you dive through enough UI layers or use old URLs to find soft-deprecated features.
Also, honestly, 100 commits = 1 transaction? That's far more of an over-simplification than anything I've said. It's a massive product with thousands of engineers, there's no chance at all it's just one database.
Commits are not expensive, pushes are. You can do any number of commits before you do one push, unless you are editing online, in which case every act is it's own commit & push.
You can rig up a local ide to pathologically commit+push per save, but you can do literally anything, so what you can do is immaterial.
Do you have some GitHub architectural knowledge you’d like to share with us?
A push pushes commits and blobs and trees and tags. It’s an interesting metric to track, but the core unit of complexity (and expense) worth tracking on GitHub’s side is obviously the commit.
There’s a difference between pushing 1 commit and 100.
> There’s a difference between pushing 1 commit and 100.
There isn’t much. GitHub doesn’t run actions separately for each commit. It runs them on pushes. I’m trying to think of a thing that would happen for each commit in each push and coming up blank.
It does things like scan for references to issues to index, but it would just scan the log for a range.
I did disagree with GP though because there is no reason to assume that the ratio of commits to pushes has materially changed. So if that is the proxy they have always used for measuring growth, and they know it reliably does that then I think it’s a reasonable way to communicate this to this audience.
Sure, because pushes are how you update a reference. That’s really what triggers an action: a reference changing. And there could be a bunch of those in a push.
A commit costs storage, you’ve got secret scanning, it needs to be indexed in a way that can be referenced in commit messages and comments, a commit message itself can close issues or reference other PRs, stored and served individually and immediately via the web UI or git clients, etc etc.
None of the things you mention - indexing or secret scan would be done individually for each commit. As I already said, this would be a log of all commits in the range pushed - it would be scanned once for those things. There is no need for a loop running over a range of commits and processing each one.
There 100% is at least for things like secret scanning and message parsing.
Secret scanning needs to make sure my repo as a whole has no secrets. It’s not acceptable to have 1 commit introducing it and 1 removing it because the secret is still recoverable.
Every commit is also surely an entry in a database somewhere. I can navigate in GitHub directly to any individual commit so there is definitely some overhead of some type.
>You can rig up a local ide to pathologically commit+push per save
The dev system we use for a 3rd party hosting provider (a big one) requires a commit and push for every file save while we're developing. I created a build system for this that copies the whole repo to a temp folder. As we save changes to files in the main repo folder, the build system watches for changes and copies the changed file to the temp folder, then does a commit on the temp folder and pushes to a an intermediary repo in github which then triggers an action that causes the 3rd party system to update from the intermediary repo. This way we don't pollute our main source repo with a commit every time we save an update to a source file.
It's not my favorite way to develop but it's caused us no real problems except when github goes down.
I don’t think I could imagine a stupider idea than this if I tried. To paraphrase Babbage: I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a solution.
meh, it's just external undo button. It's useful. It might or might not be worth the cost, but it's not that it delivers no value or causes some harm (other than cost/reliability)
I had an interview with someone who has refused to use AI, and he has been unemployed for 2 years since graduating.
On the bright side, if my 6 year old can make 3D video games, I expect seasoned programmers to be able to pick it up quickly. I think ego is the hardest thing to break.
Serious question: do you think your 6 year old is learning coding from prompting an AI?
I have had excellent results from using AI, but it’s only because I understand what it is I’m asking it to look at, and know when it’s wrong. This is proven on a nearly daily basis at my job, where, with identical agents and prompts, I see designs being pushed with objectively incorrect facts, sub-optimal code in PRs, and a general explosion of slop. That tells me that it still very much matters if you know how to do the job without the help of robots.
> I have had excellent results from using AI, but it’s only because I understand what it is I’m asking it to look at, and know when it’s wrong.
That knowledge will be worthless 12-18 months from now when AI does everything better than you, including “understanding”.
If you’re one of the world’s best programmers, it might be 24 months instead, but the writing is on the wall for everyone.
I wonder if people were behaving like that for other revolutionary technologies in the past. “I can still run faster than a car can drive in sharp turns on a gravel road…”
Not that impressive when you realize it's mostly due to AI slop
edit: AI actually writes 99.9% of my code these days. I'm just saying of course the number of commits to github is going to climb astronomically due to AI.
Impressive for whom? It's impressive for the service to have such growth at that scale, the code being slop is somewhat irrelevant. Your comment just seems like mood affiliation (AI should be dismissed, growth was from AI, therefore growth should be dismissed).
Is it impressive? All it's doing is decaying the services. 15 years ago never have imagined I would go to the lengths to host a github alternative on a VPS but after doing just this (also being the last one in the my professional group to do so), GitHub is giving a master class in destroying their reputation in pursuit of advocating for hostile entities.
Not all growth is good, especially growth that is actively hurting the company.
There is an equilibrium in both nature and software. Purposely designing systems that mimic the effects of cancer is going to benefit who exactly?
This growth is surely good for github. If another company becomes the "github for AI agents", they'll lose not just their business for AI but also human coders. (Sure, maybe there will be a human coder only github, but it will be quite small.)
How is it impressive if we all know it's autogenerated? There's no more people there than there were before. Heck, at ~2x growth that's possibly a decrease in real humans there since bots generate loads of them per person
That's not how I read the statement "It's impressive for the service to have such growth at that scale" that this was a reply to. They do seem to think the growth is impressive, not the absolute quantity, about which I agree with you
Yeah, seems like AI slop is going to kill GitHub's free tier. I just don't see how the economics of having to host this much slop and provide service to slopcoders is going to convert into dollars for them otherwise. None of the humans involved are going to end up in big enterprises. It's all cost, with no pathway to revenue.
Agree - this reminds me very much of the old joke of two economists increasing GDP by taking turns giving the same 200usd back and forth for having each other eat shit.
Useful / impressive for whom is the question.
Not for us!
We pay for Github enterprise, and because GH can't be bothered to separate service tiers for sloplords and actual paying customers we get garbage level performance. They could of course always implement usage limits, but the goal is not to earn money, or provide a good service, the goal is to maximize AI users. Would be very awkward at the next executive golf meetup if you couldn't point to increased AI adoption.
In short: This is why monopoly laws matter. Once a company becomes too large, normal business rationales cease to be the motivation for their actions, and GH can go along with the pied piper of AI psychotic C-suite officers like MS is doing instead.
When a service that was already the primary git hosting provider for most of the world for 20 years grows at that rate its not mundane and its not comparable to any example.
The absolute number doesn’t matter nearly as much as the change in rate of growth. The number of commits had not been doubling every six months at GitHub for a long time.
At Amazon if traffic volume consistently doubled every six months that is actually quite a lot easier to plan for, it just becomes part of everything they do from very early on.
No one said it is unique. But if you take an infrastructure and engineering org that had been growing at 10% a year for a decade, you are going to have a different set of capabilities and practices in place. Adapting to a new reality of doubling every few months will predictably produce failures anywhere. GitHub is not unique in that regard.
They have what amounts to an unlimited budget for AI spend. If it’s so fantastic, why can’t they let it crawl over every piece of their codebase, every metric, every log, and spot these problems before they occur?
“We misconfigured a sidecar” is something I would think AI could quite easily find and fix.
I don't know who you are responding to. I haven't made any statements about what AI can do for them. I would expect AI is making the situation worse, like it is in many dysfunctional tech organizations.
Eh, I would be more empathic in this situation[0].
Github isn’t small startup, where other 10x threshold is as cheap as buy bigger box in your IaaS.
When you are already biggest player in the ecosystem and you suddenly get 10x persisted traffic, with at least 30x+ forecast “soon” - I am not surprised they have issues.
Not sure to be honest, from a machine perspective 2X should never be a big deal, unless 1.4 was the threshold or sweet state and no one thought too much about scale and architecture beyond that
If you’re the size of GitHub and you’ve been running your infra for years with very little variation in traffic patterns you have a strong incentive to optimise costs for that existing behaviour.
I am afraid thats now how infrastructure works from what I have seen. The number that really matters is QPS. For any system the QPS varies through out the day and across the week and months. Most design considerations easily absorb any 2X increase. Pick up any company and the chances are that the servers are over provisioned, no one takes chances specially with critical components.
What you have going on with Github is mix of multiple things. Traffic alone is not the cause from what little I know, it does adds to the problem for sure
1. Infrastructure is being moved to use Azure, and overall all the cloud providers are struggling with hardware at the moment (same is going on for linkedin too)
2. The core teams, the people who knew the existing systems have either been laid off or moved from Github
3. Microsoft veterans are brought in to fill the gap across the board, they are trying their best but its a lot of unknown for them
How much infra have you seen of the top 100 sites in the world? I've worked on multiple top 10, and absorbing a 2x increase (and the peak is very likely more than 2x) is a very very hard problem that would cause hundreds of pagers to go off and load shedding to very high degrees. There is just not tons of unused capacity lying around in wait at the scale of github. "No one takes chances with critical components" is also very wrong for the simple fact that you don't know which is the weakest link in the chain until it fails.
I have some good experience and I feel bad about state of these things too specially given that a lot of it could have been prevented. What you have here is not a single service, its a system compromised of hundreds of services, possibly without clear ownership for some of them after these many years and reorgs. There is not a single person or group that understands the whole system from technical standpoint and pressure points. It akin to people trying to plug the holes as the water starts getting under pressure from different joints. This duct taping is present in almost all big enough systems, you name them.
> "No one takes chances with critical components" is also very wrong for the simple fact that you don't know which is the weakest link in the chain until it fails.
These companies were built and run by people passionate enough for the craft, ones who cared for the systems, who designed them. There is this idea that you can replace people by process and everyone is replaceable. What you have is a classical state where people are just doing their time.
I applaud GitHub. However, I think no matter how valiant they are they will not climb out from under this. The scale problem will keep getting worse, and it's getting worse in a way I don't think is translating to more money for them. Sooner or later, they're going to have to charge for things currently free.
Where in those ~12 billion commits is the software, products and "innovations" which are supposed to be making our lives better? Software and apps in particular are getting worse, normies hate AI more than ever because they're even less likely to get their desired outcome when calling their doctor or trying to get their online order refunded when chatting with a cutely named chatbot, wages for (most) knowledge work are being driven through the floor, artists are being squeezed more than ever, etc., etc. That's to say nothing of the existential threats to the economy, environment and critical thinking which are growing daily. I really think we've lost the plot, folks.
There's something poetic about a company that's leading in the realm of funding, researching, using, selling, etc. AI is actively watching the destruction of one of its core products due, in large part, to that same AI they're selling.
Everyone suggesting that they simply charge users for commits to drive off AI-heavy users forgets that Github is owned by Microsoft, who has a big incentive to keep having developers use AI.
I suspect that Microsoft would even prefer to have Github operate at a loss, if that loss were because all its users were using their models and paying for OpenAI subscriptions to generate the code.
Conversely, what suggests GitHub has a huge operating cost?
Running a GitHub clone at their same scale as a customer on cloud pricing would likely be insane. But y’all know infra is actually quite cheap when you run it yourself right?
It’s usually the case with these M&A deals that the profit just never quite makes sense to justify the purchase price, unless you can truly scale up the user base or revenue model. GitHub was already so mature as a solution when they bought it, I don’t know that they could have added that type of value just by slapping a Microsoft logo in the footer.
It used to be, and buying a few servers was a cheap way to get off the cloud (if you can manage them efficiently). But with RAM and other costs these days... I've had to rethink it a lot.
They could do this in a way that lessens external pull requests.
For example, bolting co-pilot on to github, or a Codex in the web kind of thing that gives unlimited check ins.
It's like how Grok Heavy gives the user X premium or whatever. You charge for the tokens and give the unlimted premium access as a bonus. Basically, bundle it.
operating at a loss and non-operational because of outages are very different. If they can't maintain service levels nobody - AI super user or quant, old-fashioned human - will be happy.
Possibly dumb/silly question.... Are there any sorts of reverse proxies out there that provide their own layer of jittered/exponential backoff based on patterns? (i.e. requesting IP, cookie, etc.)
I suppose the main reason I think it might be a bad idea, is that it would add complexity to the reverse proxy (i.e. now it's having to track whatever thing is being used and that complexity itself becomes a potential failure point...)
(To be clear, the clients should have their own backoff procedures, but I'm thinking about cases involving naughty clients, which are sometimes a harder problem to correct for...)
I believe envoy has it built in and istio (uses envoy) has different levers for circuit breaking and retries. I’m sure lots of them have it as an option though outside of these.
I always add some jitter but never actually had a problem where it would have been relevant. Recently I added it to a project where others also see it (not just a hobby thingy but something at work) and I was wondering if it would look silly, like premature optimisation. I looked on Wikipedia for how established the practice is and it barely gets a sentence... with no reference.
Do you know of a documented instance where it would have helped?
This doesn't answer your question, but I faced an issue where an application had to retry if things failed and I ended up with the "thundering herd" problem and introduced jitter without knowing it was a relatively standard practice.
I felt dirty implementing such a solution (introducing randomness for the sake of randomness is off-putting), but it worked. It wasn't until a while later that I even heard the term "jitter" in this context and realized this was a pretty decent solution for this kind of problem.
Regardless, if you're going to introduce something where adding jitter is appropriate, I'd just just add jitter. It's not premature optimization; it's an essential part of that kind of functionality.
It’s not hard to get started, it’s a case of adding small amounts of randomness.
If you have, say, a long poll then kick off all users due to a deploy or error (or a broadcast message) then you can have a situation where you’ve got a huge clustering of connections at 1 minute, which spreads very slowly out as real life issues give you jitter for free. You can avoid this or at least return to normal much quicker by adding some jitter.
It might happen if all your users back off at the same rate too, if the clustering causes a bunch of errors. Error -> lots reconnect 1 minute after -> fail -> lots reconnect 2, 4…
More likely to occur in cases where there’s a way you can have people all connecting at the same time - synchronisation to a real world event is one case and then connecting again at the same time after.
You have thousands of users connected to a chat via websockets to a small cheap server that can just handle the load. Server has a hiccup, all clients disconnect, server comes back, all clients reconnect at once. Server can’t handle the load.
Downstream database of our edge serverless platform went down. A tonne of requests failed all at once. Every service in the microservice request path, and the client, had their own retry policy.
Clients all retried at the same time. Retries amplified in our microservice graph (1 request at the front door ended up with like 10s of retries internally as each downstream microservice along the path retried requests). Request queues backed up and couldn’t drain fast enough. Clients all timed out at roughly the same time. All waited the same time. All retried again at the same time.
It was a pulsing thundering herd of many hundreds of thousands of requests at the front door that was amplified by internal retries.
Had to tune up load shedding to 100% after the database outage was mitigated until the backend recovered then tune it down in increments to restore service.
Added jitter to clients and turned off retries on the serverless platform.
Exactly, without jitter the thundering heard problem turns into trying to escape a small island with a small boat and big waves hitting the shore problem. You can never fully recover before you get smashed again.
If you’re talking about internet clients, I think the real world provides sufficient jitter. If you’re talking about a fleet of clients on your 10gbps network, jitter might be useful.
I've had to simulate jitter recently to reproduce a memory spike in a go app using traffic control (tc). have you observed how your app works under jittery network?
Exponential is also overkill (even with jitter as others have mentioned).
I seem to remember there was a "you failed 5 PIN entries in a row, please wait 500000 seconds before you retry" on Apple phones. So, you probably also want a sensible max... which makes exponential a bit pointless. Just do a basic fixed delay + (large, e.g. 0.5 x the delay) jitter and you'll be fine for most things. You can add a bit of cumulative delay if it's really costly to do retries.
>We have since added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity. We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure.
Are retries bad?
These are the sort of reason they make me generally uncomfortable. I appreciate they might be useful in scenarios where connectivity is inherently problematic (e.g. mobile connectivity), but for a super connected and very desktoppy service I'd rather not retry much, if at all. As it obscures it when stuff has genuinely gone wrong, and this worst case scenario is tragic.
I feel like I'm mildly stupid in trying to out retries as heresy but I'm not sure.
Seems that retries are good when the error is rare, and bad when the error is common. Typically outages have you transitioning from "everything is fine" to "nothing works", so being able detect that transition early is helpful
Retries are good, conditional on having a client-side circuit breaker that stops retries quickly when nothing is working. Otherwise, they are good in good times and bad in bad times.
This is one of the scenarios where I feel we as engineers should have been more diligent in publicly writing down what techniques have worked in which scenarios and what haven't, and the AI could have gathered decades of operational knowledge and provide proper guidance to architects designing new systems.
It's also true that we're witnessing unprecedented levels of scale.
Thundering herds and circuit breakers are extremely well documented and practiced in production. AI absolutely knows about this.
But knowing when to use which strategy and when a simple retry suffices is precisely the type of thing humans will remain to be better at than AI for the foreseeable future.
Exponential back off retries could hide a real issue, but I would estimate something like 99.99999999% of network retries are resolved within the first 2 attempts.
Not using retries is optimizing for the astronomically rare case, which is better mitigated by other means
I totally agree with you, I think retries are overused, with the exception of operations that are known to be unreliable and can't be improved.
In my experience, errors which go away within a few seconds are quite rare, and are mainly due to flaws which are usually caught in testing.
I think a very careful cost/risk/benefit analysis should be done when adding automatic retries to things. As well as potentially causing cascading failures, it is a degraded user experience when it doesn't succeed.
As a user I would rather see an error straight away than see many seconds of spinning while something silently retries, and THEN an error.
I have the exact opposite view. Way too often, I’ll be presented with an error to the effect of, “something went wrong, please try again” and often the retry works. And I’m left wondering why this machine whose sole purpose is to automate things can’t do that for me automatically.
In particular, networks tend to be a LOT less reliable than the typical developer accounts for. And the failures are very often transient. A case I run into often is doing something with my phone while leaving the house. There’s a window where it still thinks it’s on the WiFi but it’s too far away for it to work anymore. Initiating an action in that window often produces an alert telling me to try again, and trying again a few seconds later almost always works.
The Github outage was about internal clients. Phone apps are a reasonable place to say things are known to be unreliable and can't be fixed. Your IP address changes when you leave the house.
Btw, PWAs added offline capabilities to websites. I hate how the only thing that got used for was these stupid pages that look like you were able to reach the site but it's actually just saying you have no internet, like YouTube.
I was using claude tethered via my phone, and would lose signal every now and then as we went through a tunnel. I was glad for how resilient it was its its eventual retries.
The current infrastructure cannot handle the new load requirements. Either the infrastructure must change, or they must start denying users the ability to use the infrastructure.
Centralized source code hosting is going to end up looking like the three credit bureaus in terms of security. It's only a matter of time before the first big hack, when everyone shrugs and says, "Oh well, everyone's source code leaked lol too big to fail."
Given the jailbreaking behavior of models in Anthropic and OpenAI, as well as Microsoft allowing Copilot access to client data, we should assume our source code on Github is leaked or leakable anyway.
The 'growth in completed actions runs' graph is interesting. I assume the periodic drops are weekends, so intuitively the floor of those drops corresponds more with hobby/personal projects than people at work. It looks like there's a sharp uptick specifically in that floor since July ish.
Distributing across different services wouldn't be a bad idea....
I still can't help but feel a little grateful for what they do across the free side of things. I know it isn't altruism, and I know nobody needs to defend a billion dollar corporation but...
Name another service that does what they do for FREE (and no ads) at this scale. It isn't easy. Wikipedia has probably more usage, but is a simpler endeavor. (except the moderation part, that's just amazing) Open Street map? Smaller and simpler. Internet archive? Again, smaller and simpler. Linux distro mirrors? Again, smaller and simpler than whatever github is doing for free.
I don't know where else to ask this but it's killing me. Does anyone know what the hell that GitHub physical CD thing was about? Did anyone in the world get theirs?
Is it me or is all of this essentially "we don't want to show the user anything at all when something breaks?"
And what makes this funny (to me) is that this is a website for developers. I would think that of all the audiences you would target, developers would mind seeing the platform display error messages when things break the least.
Haven't they been migrating to Azure for a few years? How is it still only 58% done... Microslop needs to lay off the focus on AI features and get it done
Is git still the best VCS today? I ask because it seems so much effort in the industry has been invested in making git scale, like Cursor's Origin, or the stories in the past with Facebook's monorepo, but they all seem like bandaids to its intended design.
Can you imagine the flack he'd take if it turns out he'd been moonlighting whilst the GitHub ship is sailing though cat 5 with both the mast and the ship whore on fire?
Unfortunately time and time again, the overwhelming majority of people show that they would rather deal with an unreliable scummy company for "free" than pay $1/mo for a reliable service which treats them with respect :(
OK that "treats them with respect" is certainly an important aspect though. It does not seem like GH is especially great on that one, including listening to its users.
I wasn’t being completely serious with my suggestion, but I was thinking of a totally PAYG model. Monthly plans could come with credits, like they already do for Actions.
the retry loop that made the outage worse is just the internet being extra helpful. every client decided the best way to help was to ask again, louder.
> Copilot services took longer. Errors in those services triggered a client-side retry loop that increased traffic during recovery.
Let's pretend that the scale traffic is with the number of commit/pr and not self-inflicted with all the copilot eye candy features that were vibe-coded-added to GitHub.
In addition they say that they will continue their migration to azure and that azure is supporting their actions run.
But GitHub actions is one of the things that was the most constantly broken without multiple outages recently. So I have the feeling that it proves the point that part of the stability issues is also due to their forced usage of azure.
The trend line does not tell you what will actually happen at scale, even if you think you're perfectly prepared for the next 10% or 20% growth. As Mike Tyson put it, "everyone has a plan until they get punched in the face".
The problem is there are a class of problems that only appear after you go over the tip of what your system can handle, which are very difficult to predict or model.
Reading this port-mortem / plan shocks me, this doesn't look like a service that has been serving high-throughput services for more than a decade. In fact it is almost like they've barely started. It seems the solution has been capacity, capacity rather than architectural or data changes.
> Our next milestone is an architecture that scales read capacity linearly with the number of readers, enabling unlimited read operations
How do you not have read-replicas / read caches at this scale yet? Which is what I am reading from this statement. You can of course get really far with sharding and whatnot. But at some point it might become worth it to engineer your data into a model that scales better.
> this doesn't look like a service that has been serving high-throughput services for more than a decade. In fact it is almost like they've barely started.
Well that's because in comparison to the absolute flood of traffic brought on by AI, they really haven't been operating on this scale before.
Great read - I'm glad they realize there's work ahead but what I'm missing is:
* Paid customers: we know you pay us often a ton of money, and we burn your month on actions during these outages - we'll refund you for the days we spent your money and gave you no value.
* Paid customer: We know you put your trust in us, so we'll ensure we have a separate pool of capacity to ensure we can keep that trust.
* Paid customer: we'll proactively refund you when we miss our SLA.
What I read from this is:
* Scaling is hard, we don't have enough capacity
* We give away a shitton of compute for free
* I have to talk about Azure not being a steaming pile of poop, otherwise my bonus will get tweaked downward in the next comp cycle.
Notice there's nothing about paid customers, I'll add in what they are missing:
Paid customers: Go F*ck yourself, you don't pays us enough to be an interesting line item compared to windows server.
This. I own a small company with 5 people. I pay Github $250/m. I'm sorry but the narrative of, "look at this burden we have, it's hard to take care of all of this code!" is pretty insulting when I'm paying $50 per person per month to host code and run CI pipelines. If they do not want my money, I'll find a company who does.
With all the software being written on github you'd think we were going though a software rennasance. Where are the results? Is it really just all slop?
Why not identify the lunatic top 1% of free user you know are just abusing the hell out of the system and put severe rate limits across the board for those organizations/accounts?
With all the outages at GitHub there has to be someone willing to unseat them as the social git repo… how bad does it have to get before folks go elsewhere? Bitbucket and gitlab exist but are pawns compared to a king no?
As I mentioned before (https://news.ycombinator.com/item?id=49333107), they can mitigate these issues with limits, even for failure cascades. There should've been an all-hands-on-deck feature freeze 6 months ago to implement the limits needed. That clearly didn't happen.
I think it's because their leadership actually doesn't care that it goes down. A weekly outage is now an accepted cost of continuing to allow unlimited free access with infrastructure that cannot possibly handle the load. As a result, everyone is looking at their GitHub Enterprise bills and cost of stopped work, calculating how much they'd save by self-hosting.
"We are committed to fixing these problems, as long as it doesn't involve buying things other than AI computers, hiring humans, or using non-Microsoft products."
Calling Azure the solution to this problem when it is in fact the source of most of these problems is just fantastic doublespeak.
Github is ripe for disruption and I hope it is disrupted soon.
"While accelerating our migration to Azure," meaning, they will only solve problems if it helps them also use Azure more.
It is unbelivable that aload of 2.8b commits was totally fine, and a load of 2.9b was a sitewide outage, unless they have no reporting or their tooling is completely incompetent. If things can fall apart so easily, throwing more capacity at the problem won't fix it.
You’re torturing your own logic to make Azure the villain here. And it also sounds like you lack experience with capacity exhaustion. Things fail slowly, then suddenly.
I’m firmly in the camp of “something stinks at GitHub” but
> It is unbelivable that aload of 2.8b commits was totally fine, and a load of 2.9b was a sitewide outage
In my experience, there are hard thresholds that get passed that expose hidden bottlenecks like this. A previous system I worked on we had absolutely loads of headroom by all of our measured metrics, but one day we filled a cache because the value hadn’t been tweaked in recent memory. Plenty of space on disk and in memory, but all of a sudden we went from a very high cache hit rate to a very low cache hit rate, and everything ground to a halt.
This absolutely can happen in large systems. If some part of the system is at capacity, then slightly increasing the load can cause it to fall behind and start accumulating a backlog.
These backlogs can cause clients to make more retries, exacerbating the problem. Potentially further cascading through the system.
Sure. But you might not even be realizing that something is just at the cusp if the load is spiky enough.
The art of large system design is to identify and avoid these kinds of chokepoints. And when something happens, propagate the "backpressure" up the stack to avoid queuing.
Ok, but there's no universe where a major Microsoft-owned property is not being forced to run on Azure. Just like AWS pushing to get off Oracle back in the day. It would be career-destroying to suggest otherwise regardless of technical merit (and tbf, no infrastructure is bulletproof, unless you want to port GitHub to z/OS on mainframe)
Azure just has very poor performance and reliability characteristics. It’s a particularly bad migration target for a colo-based company that mainly runs on owned hardware (such as GitHub or LinkedIn). Requires much larger architecture changes than (say) a company coming from AWS.
I'm betting on Tangled and Codeberg. Tangled has a better press and in general is a dark horse, Codeberg has the "brand" and some network effects from projects that moved to there. (famously, Zig.) I heard that Sourcehut is having a moment as well, and I love the idea of email-based workflow and not having to have an account to contribute to someone's project hosted there, but I'm not maintaining anything worthwhile paying the $4/mo sub.
that is more manageable but c'mon I can't even keep Google One 100GB up on a consistent basis, that's how poor I am. self-hosting would be a far better option because apparently I find enough people to provide free Hetzner VPSes and stuff as long as I can sell this as mutually beneficial.
for context, I would GLADLY move there my Neovim plugin. all it does is brings the current jj message into your editor and lets you integrate it with a status bar (or anything in nvim, really). that would be a decent measure against drive-by slop contributions, and I'd accept contribs over private github mirror from those who I know but can't bother setting up git mail
EDIT: TIL that one can host SourceHut themselves. discoverability may still be a problem (sr.ht just ranks higher in search engines) but 1) fixable with github mirror that points to sourcehut instance as a canonical development platform, 2) it's moderately easy to sync contributions between tangled and sourcehut, so tangled is also an option
EDIT 2: the email part would be PITA, so $4/mo is attractive on that background
> We have since added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity. We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure.
A server box now has around 256 CPU cores. So that's about 12000 servers. If each one is $10k that's $120 million. Not a lot compared to Github's income.
$10,000 is only enough for CPU cost (2x AMD EPYC 9754). The rest of the servers (mainboard, RAM, storage, power supply, network card, rack, cooling, etc.) can easily triple or quadruple the cost.
Microsoft don't release the costs as you know, but
Compute and Storage for Free Tiers: Hosting code for over 150 million developers and processing over 2 billion GitHub Actions (CI/CD) workflows a month requires astronomical server power and data storage. The "Free" tier is a massive cost sink that Microsoft treats as a loss-leader marketing expense
Let me know when you understand how that's not free.
If you're a big company, you can afford having one engineer spend one or two days per year to maintain your self-hosted GitLab or Forgejo. On top of better reliability than GitHub, you'll get the additional bonus that your source code won't accidentally leak through being in Copilot's training set.
If you're a hobbyist, Codeberg is great, has a nice community and automatically shields you from slop contributions.
Speaking from experience, it cost mW about a week or two per year to maintain GitLab for the startup I worked at.
My personal GitLab on the other hand really does take only a day or two per year.
That said, a week or two per year is just what it costs to maintain any one thing period. I spent about that much time maintaining PCs in the office, or my personal proxmox setup. It's not onerous at all.
GitLab is super bloated and a little sucky to admin, but it's not too bad all things considered. I'm admin in my new job's GitHub org and it sucks a whole lot more to maintain.
The issue with these systems is that they lack Github's sophistication for issue tracking, knowledge transfer, and automation. I think Gitlab is a mature product in its own space and unlikey to change, for instance, at this point.
Codeberg also has the issue of having a political stance which means they will not accept just anyone's use of the platform. That is absolutely their right and I have no issue with it, but it's unattractive to me - as someone who agrees with most of their current politics - because the day they decide they don't like me, I'm screwed.
I never found GitHub's systems for issue tracking to be all that great. Cross-repository issues and development plans are hard to track within a git host. I've always used an external panning and issue tracking tool, mostly Linear, and it works really well. GitLab's Linear integration is excellent, FWIW.
I've actually worked with a couple of companies who do use GitHub for their code, and they all use Linear in addition to GitHub.
I understand the concern you're talking about wrt. Codeberg, but I wouldn't view it as a significantly bigger risk than anything else. Any platform can suddenly decide that your project is against ToS (GitHub will absolutely not accept just anyone's use of their platform either) and Codeberg introducing some rules recently doesn't, in my mind, drastically increase the risk of a dramatic ToS change in the future. But we all have to make our own risk evaluations and I won't judge yours. Luckily, moving between Git hosts isn't that difficult; setting up CI again and losing merge request history does suck but it's not the end of the world, unlike something like, say, losing your AWS/GCP/whatever account.
"sophistication" seems like a strange way to describe GitHub to me - I've found in every individual aspect (code browsing, issue tracking, code review, package management, etc), it's the worst out of all the systems I use regularly... But it's good _enough_ for most people, and it has all those features in one place, which is more convenient than wrangling 10-15 high quality but disconnected systems
Gitlab has the benefit of having very little traffic, both free and paid. Their limits are still way above the current usage so less likely to be an issue
Worth mentioning GitLab's paid enterprise offering are more expensive than GitHub's, on a per-seat basis.
Lots of companies moved because it was cheap, but it's not anymore. Ironic that companies might choose to migrate to them now for stability, rather than price.
Dude no one uses github tracking for anything serious, come on. The only thing github has over gitea/forgejo is discussions. That's the only real social "innovation" github has contributed to open source development and it's just a shitty tacked on forum.
Also for accuracy, Codeberg has a pro-human and anti-corporation stance. Both of which are definitely en vogue at the moment.
Much better than GitHub's pro slop sentiment, which is doing nothing but destroy their reputation.
I said in another thread that they can't blame increased demand for these outages, but the demand growth is genuinely insane for a company already operating at huge scale.
I guess we'll have to wait and see if they deliver now, but it seems like they're taking it seriously at least.
We need to have a package of FLOSsoftware that you could run on the cloud of your choice that offers most of what GitHub does (niceties on top of Git) without the centralization.
GitLab was close last I remember but there was some sort of enterprise tier when I tried hosting stuff on a local server years ago. I want true FLOSS, not another SaaS equivalent of the coke dealer giving clients the good uncut stuff when they're just starting out only to sell crap when they're addicted.
Forgejo is pretty neat. Their CI story is sad because it's based on act and it lacks features like GH Apps so service accounts are not possible (using a user account as service is barf).
I self-host it and its pretty easy to have uptime higher than github when you have 3 users total.
"Forgejo is a self-hosted lightweight software forge"
That says absolutely nothing. The "What is Forgejo?" question is unanswered and instead you get a lot of words about their values, their inclusivity, etc. And the next thing in the docs is how to install it. It's ridiculous.
“Software forge” is an established[1] term by this point: a piece of software providing a full set of features for collaborative development, usually at least code hosting with a web interface, tickets, and webpage hosting, and these days often also code review and integrated CI or at least the possibility of integrating CI. It’s admittedly squishy but in the same way “IDE” is squishy, which is to say it’s still well-defined enough to be useful.
> a package of FLOSsoftware that you could run on the cloud of your choice that offers most of what GitHub does (niceties on top of Git) without the centralization.
Exponential growth. No company could handle that without some issues. Good luck to them. And for those who cannot tolerate this, there are many self hosted options.
And another outage. [0] Looking forward to the subsequent post-mortem on that one.
You might want to not go all in on GitHub anymore since it is very unstable to use. A self-hosted instance would have a far better uptime than GitHub over the years.
6 years ahead [1] on not going all in an centralizing everything on GitHub.
It's funny, I bet you could take any software dev and blind AB test a page written by a corporate manager and a page written by an engineer.
Here's something an engineer writes, loaded with facts:
"I got to the office and we had a huge panic going on, I immediately called our IT in US-2West and they reported on cascading box failures, I checked our load balancer via remote admin and indeed it was failing to. I called my IT managers and learned we had hard resetting in progress for the past 20 minutes with minimal impact on recovery."
This stuff is good! This is what a booming economy looks like. There are people out there competing with you for resources because they have cool ideas they want to implement.
Or at least they asked the AI to come up with cool ideas, which is even more interesting. It's exciting watching the world transition away from humanity being in the driver's seat!
Layoffs by the 10s of thousands, food prices out of control, people barely able to afford gas. At least some tech bros can launch their 50th B2B SaaS. I didn't realize a booming economy sucked so much.
The exciting thing about AI is precisely that it'll let software move beyond Yet Another B2B SaaS and into doing useful things in the real world. I regularly ride in driverless cars! That was the stuff of science fiction when I was a kid.
If you're worried about food prices, you should be happy that robots will make agriculture less labor-intensive and bring prices down.
How would any of what you're saying help with this?
> The immediate cause of the failure was network saturation on load balancers in Central US due to a new peak in traffic. Originally this was caused by an Istio sidecar pod reaching its concurrency limits and failing to auto scale correctly because of a misconfigured policy that watched host service but not sidecar limits. One failure cascaded to more and eventually four HAProxy nodes exhausted their flow limits, degrading the gateway auth path and causing widespread authentication latency and failures. The problem was worsened by optimistic retry logic which overloaded internal load balancers. Pausing HAProxy on those nodes simultaneously produced immediate broad recovery.
load balancer failure? rate limit woudl address
concurrency limits? throttle or queue up messages. auto-scale failed cause was misconfiguration policy, which i admit cannot be handled by my suggestions.
The cascade? it's downstream service degradation, which I mentione should have had been prevented with queues. One of the jobs that queues/kafka solve is to prevent these downstream outages.
If your LB is down, you're just kind of screwed. You can't enqueue things if requests aren't getting through at all. Same deal with authn/authz issues, which they also had. If you can't answer the question "is this message allowed to be added to the queue" you can't enqueue stuff.
GitHub does use queueing for all kinds of stuff internally, though, because they're not morons.
I strongly disagree. GitHub, a year ago, acknowledged the fundamental problems and began work on them. We all agree with the diagnosis and strategy: stop building new things, bring stability. Why would whether the CTO codes have any bearing on the correctness of this strategy? GitHub’s problem isn’t that leadership don’t understand the product, or that they don’t know what they should be doing, it’s that they’re battling unprecedented demand. If it was a disconnect between users and leadership on what matters, sure, a CTO who doesn’t use the product would be notable, but that isn’t the problem. And that’s all assuming he doesn’t actually use the product, maybe his privacy settings hide private commits.
Interesting - There's a couple of things that I disagree with here, but I do think this resonates: "We all agree with the diagnosis and strategy: stop building new things, bring stability."
Where I have a problem with the positioning of their GitHub profile is, he's the CTO of GitHub, arguably the defacto standard for open-source version control systems. His GitHub profile is linked to as the author for the post, and his GitHub profile simply tells me: "this guy doesn't code."
I don't care if this guy doesn't work on GitHub itself, I hardly would expect that, but IMO, any CTO of a company like GitHub should eat, breathe, and sleep code. He might, but his profile, which is being published as if it means anything, tells me he doesn't.
In other words, I think his private contributions should still manifest on the contribution graph. And for being the CTO of an organization like GitHub, with no open-source contributions... Not a great look.
> Errors in those services triggered a client-side retry loop that increased traffic during recovery
Symptomic of a wider trend to avoid showing the user any error at all costs, even if that means they sit watching a spinner for 7 hours.
> Delayed replies to a single internal endpoint triggered a latent retry bug in VS Code that amplified traffic by approximately 10x and caused delayed recovery for the Copilot Token Service.
The detailed root analysis tries to pass this off as a "bug". You can't seriously tell me client retry doesn't have a unit test which ensures the retry back off behaviour is functioning exactly as designed. In this case aggressively to try and hide problems if token service responses become flakey.
"You can't seriously tell me that the unhappy leg of the code path has no test coverage."
Sometimes I forget how ignorant HN can be of real world software development and the bar of corporate code quality, and then bangers like this remind me of it.
"You can't seriously tell me that the unhappy leg of the code path has no test coverage."
Cloudflare outage on December 5, 2025 [1]:
> However, we have never before applied a killswitch to a rule with an action of “execute”.
[1]: https://blog.cloudflare.com/5-december-2025-outage/
Exactly this. I've seen production level trading systems grind to a halt over a simple bug and no matter what tests you have in place, it happens.
I cannot even begin to express how many times I've seen engineers working super hard to optimize happy-paths so that we turn 3 nines of availability into 4 nines but introduce unintended emergent behaviors in unhappy-paths that turn 1 nine into zero nines via thundering herds, retry storms, etc.
You have my empathy for this kind of sentiment. Personally this seems somewhat rare in practice. That being said I'm curious if anyone has anecdotes they can share about these kinds of things?
Configuring postgres to automatically failover instead of doing it manually. The automated system caused more downtime in a few months than manually doing it did for years before. All in the name of more automations and less downtime
Could you elaborate on why that would cause more downtime?
> Exactly this.
It seems to me like you're saying nearly the opposite of them. You're saying "no matter what tests you have in place, it happens", while they're suggesting low standards and few tests.
More like: those tests are useless because the fundamental system design is garbage thanks to the incompetence of corporations.
Copilot probably wrote the code confidently and it was never looked at by a human then yolo’d out to meet the pointy haired bosses arbitrarily short timeline to then look good to his boss and so on
It’s been proven that VS Code has product managers who vibe code commits that get merged, including the co-authored with copilot bug. So there’s some problems there.
That was the final straw that stopped me using it.
I didn’t/don’t want the AI, I didn’t like the telemetry but it could be turned off but the cavalier disregard to just yeeting shit into a tool used by that many people no thanks.
What do you use now and what is your primary use case?
I use jetbrains editors, but mostly goland which might be more stable then others
I recently tried zed but it ddos’d my nas over an smb share lol
I have been using Zed lately and quite liking it. I used Jetbrains for years, but it's gotten absurdly buggy lately so I probably won't renew it. I have also used vscode and I need to use it at work, and it's fine, but I prefer Zed (fewer bugs, faster, mainly).
I always advocate for the "boomer" editors when possible. It doesn't matter which one you choose. People can say what they want about them, but very little software survives almost 60 years. I sure as Hell hope VS Code doesn't.
At some point, esoteric UIs may have been needed in the 70s, but that ship has long sailed. I don't need to give myself carpal tunnel syndrome trying to quit vim. If anything, a lot of that is also a problem that continues to plague software to this day: devs who go "well if it works for me, it's good enough for anybody, and if you don't like it, you must not be a Real Developer!"
They also charge ahead to prod with known defects and then change their story when they're caught out https://news.ycombinator.com/item?id=48032310
If you've only worked at a small-to-medium privately held company you'd assume every company ran that smoothly. "Too big to fail" makes sense once you've worked for a behemoth and not before.
This is what I think of when people complain about the quality of code from AI agents.
Test coverage varies a lot, but error paths seem almost universally untested.
Lots of keyboard warriors here, very few of them solving real problems at scale.
Ironically wouldn't someone who solves real problems at scale actually be a 'keyboard warrior'?
At least they aren't creating new problems at scale either.
I solve real problems at scale and the engineering practices I see on a daily basis are a clown show.
There's little to no basic understanding of networking, distributed systems, databases, etc. 99% of our engineers were hired from their college internships and never worked anywhere else. Industry hires to improve systems rarely last more than a year and it is almost never their fault.
We're in the next tier down from the biggest tech companies and what we do is hardly uncommon among our peers.
I should be shocked that 99% of engineers I deal with treat all resources as infinite bandwidth, 100% uptime, but I'm not. They NIH super hard and write tons of code for things that a docker container running nginx (or similar) would solve in 5 minutes. There's almost no useful testing and worse documentation.
Welcome to corporate life.
Clearly we have the same employer. Get off hacker news and get back to work!
I think a lot have mostly experienced working for tech companies and do not understand how different that is from working at some other kind of company (particularly something not technically sexy) doing tech (see last parenthetical).
Is GitHub a tech company? Because that's who they're criticising.
I mean, there are many unserious engineers in corporate America.
> bar of corporate code quality
It's Microsoft, if they can't afford to do comprehensive unit testing, what hope do the rest of us have?
It's less about "can't afford" and more about "don't want to spend".
Microsoft is very much not FAANG. They’ve been trying to eliminate dedicated QA for years and underpay contractors.
Microsoft can afford to do a lot of things, but why when you can squeeze a bit more profit out.
I have never heard anyone ever utter the words, "Microsoft makes great products and services." They basically built an empire on brand recognition and vendor lock-in. Of course, a lot of their success was due to catching lightning in a bottle a few times at the right moments.
It is miraculous how they continue to fail upwards somehow. I suppose it's because they just vampirically sustain themselves by acquiring other companies and sucking them dry until they are a husk of what they once were -- like Github, Activision/Blizzard, LinkedIn, Skype, etc.. I remember when those companies used to actually produce good products and services.
> It's Microsoft
That means nothing, especially with all the layoffs.
One thing that I learned over the years is never mystify "code quality". Maybe you can say a certain team/project produces high quality code, and maybe Google's overall quality is better than my company's (considering their bar of hiring), but you want to avoid generalizing that, especially at scale.
The average software engineer at a large company ships just enough code at good enough quality to earn a salary, nothing fancy about it.
Answer is, you do comprehensive unit testing irrespective of Microsoft or any other company doing it. Also, as the OP of your comment posted, you are over estimating the software quality of these big name corporate companies. It can’t be the bar against which you would want measure your own company standards.
A common pattern in highly available services is that sometimes you should retry immediately (because the node you hit is rolling/broken/overloaded, but the others aren't) and other times you should back off aggressively (because the service is degraded).
If your server indicates with 100% accuracy when to retry immediately vs backoff, AND if all your clients consume that information with 100% accuracy, things go great. But there are lots of situations where one or both of those breaks down.
Anyone who designs such a system should know to use an exponential backoff to avoid the thundering herd. Maybe copilot missed that while it was reviewing its own PR
Exponential backoff is the wrong answer in a highly available system in the typical case where (a) failure is expected and (b) you have nodes you are supposed to fail over to.
Your highly available system is probably somewhat important, otherwise you won’t have invested in making it HA.
While your premise holds for happy cases, when you do have a cascading series of outages, not using exponential backoff is just adding a self-inflicted DoS to when you do go down.
I don’t really follow your premise and can’t really articulate many cases for when you shouldn’t use exponential backoff. Maybe if you’re working at Jane St or something; or other circumstances where you can deploy immediate changes to the client; and you’re willing to trade ‘better p50 for worse outages’.
But in the case of shipped code that’s run on clients, I’ll continue exponentially backing off all the way, all the time, for everything.
When you have an outage, you should not retry at all. Exponential backoff is exactly how you get cascading outages. If service A fails a request to service B and decides to exponentially back off, now service A is holding open an end user request that will claim resources on service A. Fast forward ten minutes and the service B degradation has metastasized into a service A degradation. And even after service B has recovered, service A might still be dead.
To handle this correctly you need your RPC framework to accurately communicate retryable vs non-retryable failures to clients. Then service A knows service B is dead, does not retry, and proapgates the failure to clients. This is hard to do perfectly, but there's no alternative that works.
Why? You can retry, but there is nothing wrong with increasingly waiting slightly longer if we fail many times.
"exponential" and "slightly longer" are very different backoff patterns.
Try asking Opus or Fable that question. It'll give you a good answer on why microservice architectures work the way they do in order to keep user-facing latency acceptable and minimize downtime. It's a complicated enough topic that I don't feel like explaining it for free to you in a HN comment.
Why are you pretending this is a harder topic than it is and you have some secret insight. And you're a dick on top of it:
Yes, exponential backoffs alone are insufficient. Yes, adding jitter helps randomize the calls across a fleet and should be the default with exponential backoffs. Yes, both of these may be sufficient for most systems. Yes, you can dive more into circuit breakers and adaptive retries to limit thundering herd.
https://aws.amazon.com/blogs/architecture/exponential-backof...
https://brooker.co.za/blog/2022/02/28/retries.html
The whole point of exponential backoff is that the first retry can be quick.
The right answer is for the RPC framework to accurately communicate "try again on another node" vs "don't try again, just hard fail".
When one end user request fans out to hundreds of backend requests (typical for microservices), you can't have each of those backend requests do its own exponential backoff. If they do it in parallel, they're a thundering herd, and if they do it in serial, the end user request will time out before you finish all the work, at which point you're doing a bunch of slow expensive work for no gain (and the enqueued slow expensive work will make your outage worse).
This is why you have circuit breakers upstream. Not on every individual instance.
Doesn't do you any good if the outage is in the circuit breaking layer, which it was for GitHub (this started as a load balancer outage).
> because the node you hit is rolling/broken/overloaded, but the others aren't
Retries in such a situation should be handled internally with the client at most responsible for failing over with a circuit breaker to another zone. Having the client auto retry right away is not something that behaves well as shown here, even if in the happy path it happens to stimulate increased availability without actually investing in the proper architecture for it
CAP theorem. Pick one of those.
> You can't seriously tell me client retry doesn't have a unit test which ensures the retry back off behaviour
That wouldn't be a unit test - that's more like an end-to-end or integration test.
Have you ever worked anywhere that had perfect test coverage? It just doesn't happen, nor is it possible unless you're building a calculator app or todo list.
My employer has 0% test coverage lol. I've begged and pleaded, but the claim is that "risk is low" and "that's what QA is for." Hell, I've complained to senior management about how there are senior devs that forgo backend validation. It's truly Hell in the trenches sometimes.
Some days, I would seriously rather work at Wendy's.
> You can't seriously tell me client retry doesn't have a unit test which ensures the retry back off behaviour
Not to join the parade, but what would a unit test that confirms a cycling behavior across all the instances in-flight even look like? I mean, besides "Not a unit test".
Maybe the retry logic was vibecoded instead of using an existing hardened library. After all, according to Twitter, nobody is looking at the code anymore.
> instead of using an existing hardened library
A lot of retry libraries I’ve seen require the user to configure them. You can use a library with all the right settings, but if you configure it wrong, you are really no better off than if you hadn’t
They added 3 million CPUs. You reduce the complexity of their systems to a unit test…
> a wider trend to avoid showing the user any error at all costs
And in fact you can see the degradation of software over the previous decade-plus via Google Trends search for ‘something went wrong’ lol: https://trends.google.com/trends/explore?date=all&q=%22Somet...
Backend API rate limiting has to surely kick in and force you to wait x amount of time before you try again… Discords bot API actually sends you how long before you retry.
As a client you can hit a server as much and as often as you like. The only thing the server can do is return an error code or try to hold the socket open (which the client can then close on their own).
Except the other side of this is interrupting a service which would otherwise have succeeded: there's a lot of unattended or minimally attended processes where an interruption is just asking the user to do the only thing they were going to do anyway - retry it.
In GitHub's case this is especially relevant - the only reason to throw an error message at the user is the hope they - the human - give up and walk away (or you break all the CI/CD builds and the time it takes humans to hit "retry" gives you some breathing room).
For some context, in June they said commits "commits nearly doubled year over year, crossing 1.4 billion per month". Now, it has more than doubled that in just a few months.
https://github.blog/news-insights/product-news/github-copilo...
Makes sense given the ubiquity of agentic coding. I made a joke to my coworker today that all we do is make sure AI agents can communicate with other AI agents.
LOL, this kind of things will happen when projects like Bun (https://github.com/oven-sh/bun) are running on auto. :)
More than 50% of the recent commits are from robobun, jesus
3.3k open issues holy shit
and all of high quality
https://github.com/oven-sh/bun/issues/39797
And 5K PRs. I'm crying.
> 5k PRs
Wow, is Bun the record holder for number of PRs?
I recall GitHub recommends to keep the number of PR to a certain level due things such as GitHub Actions slowing down.
Nixpkgs has 11k open PRs at the moment (a lot of them routine version bumps and such), so no. But then Nixpkgs isn’t a piece of software in the conventional sense: the monorepo does contain a few of those, but most of it is a giant collection of basically-independent build scripts.
Strange to think they are probably triaged by LLMs at this point
AI finding issues in code and reporting them so that an AI can review and triage them for another AI to fix.
I mean, isn't that the dream?
I don't know if that's sarcasm or not. I know it doesn't work, but that's the future we've been promised, right?
If the same AIs don't hallucinate and create bugs in the first place.
I don't know how much my own time is wasted on Claude imagining API response formats that never existed.
It's certainly someone's dream: https://devhumor.com/media/dilbert-s-team-writes-a-minivan
Who promised it?
It really is. I know I've gone from tens a month to thousands a month. They have to be projecting >100B/month in the next year or two.
wow. they should really institute a maximum amount of individual pushes per-month per-user.
That would just drive users into the arms of the alternatives, which would love to own the world's code... like Cursor/Musk.
Microsoft and GitHub's only option is to suck it up, absorb this growth, and lower failure rates. They have the money, so that's not the issue.
As someone on the sidelines, this is really interesting to watch unfold.
Well either they can handle this load that Microsoft can't, or they can't. If Microsoft are going to continue to be unreliable in the absence of the rate limit then:
If alternatives can handle the load, those who would consider those alternatives if Microsoft opposed a rate limit are likely to move to them anyway.
If alternatives aren't able to manage, then user's aren't going to jump since those services won't actually provide more usage.
I think the number of commits is a red herring, but that said, I wonder how spiky their load is.
Imagine a fee over X commits, but only during certain hours. I can imagine 90% of the commits over 6 or 8 timezones, maybe 50% over 4 right now...
I was thinking the same thing at first: ideas to increase product limits on GitHub, to increase reliability given limited infra.
However, there are sharks in the water, and with the diminishing mean of user technical knowledge, the product actually needs to become even more free. GitHub likely needs even lower friction.
"All it takes" is the insanely heavy technical lift to support that. There is no other solution. All the C-Suite needs to do is foster an environment with well-thought through, and possibly over-funded engineering, at the edge of the art. That sounds like an amazing challenge.
It's not a red herring, every commit necessitates a database hit.
Why would any company want coding data now? It's all garbage. I'd be surprised if anything past 2025 is even used for training.
so... when you reach your monthly limit in the middle of the month, what is the recourse?
Or, is the idea just to drive everyone away from your platform?
Uh, pay money for the service you're using constantly?
I still remember when they decided to limit the number of private repos you could have as a free user. Kind of silly to me at the time, and even more so now!
I remember when you had to pay for private repos in the first place.
Initially there were no private repos for free users at all, it was a selling point for bitbucket that they offered that.
Which will just increase the cries of "enshittification" and hasten the mass migration to the next free platform that surely, this time, won't ever go down.
We're small enough that we've been hosting our git infra for about a year now, I wonder how many other companies figured out they could make the trade. I've had a Github since a couple years after they started and I think they are going to become a Stack Overflow, albeit slower with MS at the helm. If Github is going to be 99% slop it's going to be really hard to use as a fun tool to show what you can do, what you've worked on, side projects, etc. I took github off my resume and I'm probably not going to relaunch my weblog if I end up job hunting, too much low-effort crap and people basically copying what a lot of us had been doing manually for years to really feel like it's anything other than a negative signal.
I would give the growth hacker on their team a big raise, these KPIs are incredible
Truly incredible in every sense of the word.
It's almost double. If you have scaling prepared, it should be linear, but I doubt they've prepared for this.
they are/were in the middle of a migration
Why is Github talking about number of commits here, and not pushes? Are there a lot of tools/people using github as an online editing platform?
GH processes at the commit level for things (including actions) even though they're bundled in a push... it's relevant to the load on their infrastructure.
In what way? If I have multiple local commits pushed once I expect to see CI type actions to run once for the push rather than for ever commit in the push.
But they can't process the commit until I push it?
A push containing 100 commits is more expensive than a push containing 1 commit.
But is it 100x more expensive?
Probably? If you do 100 pushes instead, there is roughly zero additional data. At best you'd be comparing cache costs, which probably are lper for one large push, but there's a ton of calculation and CI that runs per commit regardless of other data being cached.
Why don’t you have your actions run on pr or push instead of on commit? Why would you even want that? I’ve never seen actions set up that way. If I push a branch with 100 commits then it’ll only run CI once. It’ll show the rest of the commits in the UI, sure, but that doesn’t mean that it’s the same performance impact. It could very well be 1 db transaction with multiple rows written instead of 100. I think you’re reducing this problem too much without knowing their architecture.
Github runs CI per PR push (obviously), and per main-branch commit (click on commit history in any project with CI, see a build result check mark on each one - that's true if you push a dozen commits too (I've done that)), in nearly all setups I've seen. I'm not sure how much of that is required vs default though.
With enough effort, you can rather obviously run CI per PR commit (it's a programmable system), but I've never seen aUI-integrated way to track the results, aside from browsing custom job names, which is very far from what I'd call "integrated" when compared to PR-level build markers. Similarly, I'm not aware of (but would not be surprised by) any way to disable per-main-branch commit builds, aside from initial pushes.
But I haven't poked around deeply in the settings, and business-account settings are rather different anyway so those might be wildly different / more flexible / more obtuse in exciting ways. Github is a very large and complicated product at this point, darn near anything could exist if you dive through enough UI layers or use old URLs to find soft-deprecated features.
Also, honestly, 100 commits = 1 transaction? That's far more of an over-simplification than anything I've said. It's a massive product with thousands of engineers, there's no chance at all it's just one database.
Bigger numbers sound more impressive.
"Our billion-dollar infrastructure crumbles under a tremendous flood of 50 PRs per second" would just sound embarrassing.
I'm not following your line of questioning. Without ever using github as an online editing platform, you can do one push with two new commits.
Commits are not expensive, pushes are. You can do any number of commits before you do one push, unless you are editing online, in which case every act is it's own commit & push.
You can rig up a local ide to pathologically commit+push per save, but you can do literally anything, so what you can do is immaterial.
Do you have some GitHub architectural knowledge you’d like to share with us?
A push pushes commits and blobs and trees and tags. It’s an interesting metric to track, but the core unit of complexity (and expense) worth tracking on GitHub’s side is obviously the commit.
There’s a difference between pushing 1 commit and 100.
> There’s a difference between pushing 1 commit and 100.
There isn’t much. GitHub doesn’t run actions separately for each commit. It runs them on pushes. I’m trying to think of a thing that would happen for each commit in each push and coming up blank.
It does things like scan for references to issues to index, but it would just scan the log for a range.
I did disagree with GP though because there is no reason to assume that the ratio of commits to pushes has materially changed. So if that is the proxy they have always used for measuring growth, and they know it reliably does that then I think it’s a reasonable way to communicate this to this audience.
> It runs them on pushes
Sure, because pushes are how you update a reference. That’s really what triggers an action: a reference changing. And there could be a bunch of those in a push.
A commit costs storage, you’ve got secret scanning, it needs to be indexed in a way that can be referenced in commit messages and comments, a commit message itself can close issues or reference other PRs, stored and served individually and immediately via the web UI or git clients, etc etc.
It’s also like… the core unit of git.
None of the things you mention - indexing or secret scan would be done individually for each commit. As I already said, this would be a log of all commits in the range pushed - it would be scanned once for those things. There is no need for a loop running over a range of commits and processing each one.
There 100% is at least for things like secret scanning and message parsing.
Secret scanning needs to make sure my repo as a whole has no secrets. It’s not acceptable to have 1 commit introducing it and 1 removing it because the secret is still recoverable.
Every commit is also surely an entry in a database somewhere. I can navigate in GitHub directly to any individual commit so there is definitely some overhead of some type.
Exactly. You can have 3000 commits in a branch, and unless you don't push each of them one by one, shouldn't be a problem the number.
>You can rig up a local ide to pathologically commit+push per save
The dev system we use for a 3rd party hosting provider (a big one) requires a commit and push for every file save while we're developing. I created a build system for this that copies the whole repo to a temp folder. As we save changes to files in the main repo folder, the build system watches for changes and copies the changed file to the temp folder, then does a commit on the temp folder and pushes to a an intermediary repo in github which then triggers an action that causes the 3rd party system to update from the intermediary repo. This way we don't pollute our main source repo with a commit every time we save an update to a source file.
It's not my favorite way to develop but it's caused us no real problems except when github goes down.
> requires a commit and push for every file save
I don’t think I could imagine a stupider idea than this if I tried. To paraphrase Babbage: I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a solution.
meh, it's just external undo button. It's useful. It might or might not be worth the cost, but it's not that it delivers no value or causes some harm (other than cost/reliability)
Not really. It's AI commits. Not quality commits.
it doesn't matter though, commits create load in their system
One has to wonder what the point of a collaborative version control system even is if the software we’re writing is one-shotted by a call to an API ?
the infrastructure does not care about the quality of the commits, just that a commit happened.
A lot of human commits are low quality
Does anyone else feel bad for people like this?
I had an interview with someone who has refused to use AI, and he has been unemployed for 2 years since graduating.
On the bright side, if my 6 year old can make 3D video games, I expect seasoned programmers to be able to pick it up quickly. I think ego is the hardest thing to break.
Serious question: do you think your 6 year old is learning coding from prompting an AI?
I have had excellent results from using AI, but it’s only because I understand what it is I’m asking it to look at, and know when it’s wrong. This is proven on a nearly daily basis at my job, where, with identical agents and prompts, I see designs being pushed with objectively incorrect facts, sub-optimal code in PRs, and a general explosion of slop. That tells me that it still very much matters if you know how to do the job without the help of robots.
Coding is dead.
> I have had excellent results from using AI, but it’s only because I understand what it is I’m asking it to look at, and know when it’s wrong.
That knowledge will be worthless 12-18 months from now when AI does everything better than you, including “understanding”.
If you’re one of the world’s best programmers, it might be 24 months instead, but the writing is on the wall for everyone.
I wonder if people were behaving like that for other revolutionary technologies in the past. “I can still run faster than a car can drive in sharp turns on a gravel road…”
It will be interesting to see if LLM can push beyond the intelligence embedded in language.
General intelligence may still be a ways off.
I mean if I set up a for loop spamming my own SAAS it would be incredible growth too
Not that impressive when you realize it's mostly due to AI slop
edit: AI actually writes 99.9% of my code these days. I'm just saying of course the number of commits to github is going to climb astronomically due to AI.
Impressive for whom? It's impressive for the service to have such growth at that scale, the code being slop is somewhat irrelevant. Your comment just seems like mood affiliation (AI should be dismissed, growth was from AI, therefore growth should be dismissed).
Is it impressive? All it's doing is decaying the services. 15 years ago never have imagined I would go to the lengths to host a github alternative on a VPS but after doing just this (also being the last one in the my professional group to do so), GitHub is giving a master class in destroying their reputation in pursuit of advocating for hostile entities.
Not all growth is good, especially growth that is actively hurting the company.
There is an equilibrium in both nature and software. Purposely designing systems that mimic the effects of cancer is going to benefit who exactly?
This growth is surely good for github. If another company becomes the "github for AI agents", they'll lose not just their business for AI but also human coders. (Sure, maybe there will be a human coder only github, but it will be quite small.)
How is it impressive if we all know it's autogenerated? There's no more people there than there were before. Heck, at ~2x growth that's possibly a decrease in real humans there since bots generate loads of them per person
> there's no more people there than there were before
Seems false. Lots of coding adjacent people, engineering managers, etc. are now pushing PRs.
> How is it impressive if we all know it's autogenerated?
Nobody is saying the code is impressive, just the growth of github is impressive. It's not doing anythign different based on the source of the code.
It's an impressively large quantity of X, not an impressively good X.
That's not how I read the statement "It's impressive for the service to have such growth at that scale" that this was a reply to. They do seem to think the growth is impressive, not the absolute quantity, about which I agree with you
Yeah, seems like AI slop is going to kill GitHub's free tier. I just don't see how the economics of having to host this much slop and provide service to slopcoders is going to convert into dollars for them otherwise. None of the humans involved are going to end up in big enterprises. It's all cost, with no pathway to revenue.
I don't know how to delete things.
And what would be the expected result (other than spending $20 a month)?
I wrote a list of things that makes us money, but I decided that I like having less competition. Now to see if I can delete my original post.
Automated slop?
Agree - this reminds me very much of the old joke of two economists increasing GDP by taking turns giving the same 200usd back and forth for having each other eat shit.
Useful / impressive for whom is the question. Not for us!
We pay for Github enterprise, and because GH can't be bothered to separate service tiers for sloplords and actual paying customers we get garbage level performance. They could of course always implement usage limits, but the goal is not to earn money, or provide a good service, the goal is to maximize AI users. Would be very awkward at the next executive golf meetup if you couldn't point to increased AI adoption.
In short: This is why monopoly laws matter. Once a company becomes too large, normal business rationales cease to be the motivation for their actions, and GH can go along with the pied piper of AI psychotic C-suite officers like MS is doing instead.
Should use on premises.
They do. Talk to your account representative for the alternate domain name to hit.
alot of distributed systems in big companies grow at this rate, its not exponential, its mundane
When a service that was already the primary git hosting provider for most of the world for 20 years grows at that rate its not mundane and its not comparable to any example.
AWS saw this growth every year for two decades, hyper growth tech sees it all the time
The absolute number doesn’t matter nearly as much as the change in rate of growth. The number of commits had not been doubling every six months at GitHub for a long time.
At Amazon if traffic volume consistently doubled every six months that is actually quite a lot easier to plan for, it just becomes part of everything they do from very early on.
im not buying that github is a unique engineering problem, harder than the rest of hyperscalars.
No one said it is unique. But if you take an infrastructure and engineering org that had been growing at 10% a year for a decade, you are going to have a different set of capabilities and practices in place. Adapting to a new reality of doubling every few months will predictably produce failures anywhere. GitHub is not unique in that regard.
They have what amounts to an unlimited budget for AI spend. If it’s so fantastic, why can’t they let it crawl over every piece of their codebase, every metric, every log, and spot these problems before they occur?
“We misconfigured a sidecar” is something I would think AI could quite easily find and fix.
I don't know who you are responding to. I haven't made any statements about what AI can do for them. I would expect AI is making the situation worse, like it is in many dysfunctional tech organizations.
ive spent 15 years in big tech companies, this problem is common and its why they pay engineers 500k-1M. this happens at meta literally all the time.
half of engineering in big tech is just rewriting a system to scale
microsoft is incompetent, they havent changed windows/excel/outlook in 30 years
Tell me about the time that an app at Meta grew at 10% a year for a decade and then began doubling every few months.
its probably happened on half the core teams, idk what you want me to say, it sounds like you dont have alot of experience
Don't dodge the question and attack the asker, that's rude.
Eh, I would be more empathic in this situation[0].
Github isn’t small startup, where other 10x threshold is as cheap as buy bigger box in your IaaS.
When you are already biggest player in the ecosystem and you suddenly get 10x persisted traffic, with at least 30x+ forecast “soon” - I am not surprised they have issues.
[0] even at current MS owned github
cloud providers and hyper growth tech deal with these growth rates all the time
Did you read the article? It is growing exponential.
this is common at AWS/cloud providers
Not sure to be honest, from a machine perspective 2X should never be a big deal, unless 1.4 was the threshold or sweet state and no one thought too much about scale and architecture beyond that
If you’re the size of GitHub and you’ve been running your infra for years with very little variation in traffic patterns you have a strong incentive to optimise costs for that existing behaviour.
I am afraid thats now how infrastructure works from what I have seen. The number that really matters is QPS. For any system the QPS varies through out the day and across the week and months. Most design considerations easily absorb any 2X increase. Pick up any company and the chances are that the servers are over provisioned, no one takes chances specially with critical components.
What you have going on with Github is mix of multiple things. Traffic alone is not the cause from what little I know, it does adds to the problem for sure
1. Infrastructure is being moved to use Azure, and overall all the cloud providers are struggling with hardware at the moment (same is going on for linkedin too)
2. The core teams, the people who knew the existing systems have either been laid off or moved from Github
3. Microsoft veterans are brought in to fill the gap across the board, they are trying their best but its a lot of unknown for them
How much infra have you seen of the top 100 sites in the world? I've worked on multiple top 10, and absorbing a 2x increase (and the peak is very likely more than 2x) is a very very hard problem that would cause hundreds of pagers to go off and load shedding to very high degrees. There is just not tons of unused capacity lying around in wait at the scale of github. "No one takes chances with critical components" is also very wrong for the simple fact that you don't know which is the weakest link in the chain until it fails.
I have some good experience and I feel bad about state of these things too specially given that a lot of it could have been prevented. What you have here is not a single service, its a system compromised of hundreds of services, possibly without clear ownership for some of them after these many years and reorgs. There is not a single person or group that understands the whole system from technical standpoint and pressure points. It akin to people trying to plug the holes as the water starts getting under pressure from different joints. This duct taping is present in almost all big enough systems, you name them.
> "No one takes chances with critical components" is also very wrong for the simple fact that you don't know which is the weakest link in the chain until it fails.
Sure, but the new patterns are several years old at this point.
Not adapting is a choice
If you grow 2x a month, you'll run out of resources very soon. Like the whole Solar System.
Hey, um. Little bit of math. Exponential growth.
I applaud GitHub. However, I think no matter how valiant they are they will not climb out from under this. The scale problem will keep getting worse, and it's getting worse in a way I don't think is translating to more money for them. Sooner or later, they're going to have to charge for things currently free.
I've been saying this for a while: https://news.ycombinator.com/item?id=47534499
> Since April, monthly commits have grown from 1.4 billion to 2.9 billion
Bonkers.
You can tell the entire industry is in a "productivity panic" and here's more proof. There's a velocity zealot crying tears of joy somewhere.
Bonkers is right.
Where in those ~12 billion commits is the software, products and "innovations" which are supposed to be making our lives better? Software and apps in particular are getting worse, normies hate AI more than ever because they're even less likely to get their desired outcome when calling their doctor or trying to get their online order refunded when chatting with a cutely named chatbot, wages for (most) knowledge work are being driven through the floor, artists are being squeezed more than ever, etc., etc. That's to say nothing of the existential threats to the economy, environment and critical thinking which are growing daily. I really think we've lost the plot, folks.
There's something poetic about a company that's leading in the realm of funding, researching, using, selling, etc. AI is actively watching the destruction of one of its core products due, in large part, to that same AI they're selling.
Cry in story points. Like a real scrum master level 9000.
Everyone suggesting that they simply charge users for commits to drive off AI-heavy users forgets that Github is owned by Microsoft, who has a big incentive to keep having developers use AI.
I suspect that Microsoft would even prefer to have Github operate at a loss, if that loss were because all its users were using their models and paying for OpenAI subscriptions to generate the code.
This is like letting someone stay in your house for free while charging them to burn it down.
> I suspect that Microsoft would even prefer to have Github operate at a loss,
I assumed it does, do you know that it doesn't?
I presume there’s a lot of companies out there paying GitHub very large sums to host all their private repos.
No doubt. ...You can have non-zero revenue and still be loss-making though.
Conversely, what suggests GitHub has a huge operating cost?
Running a GitHub clone at their same scale as a customer on cloud pricing would likely be insane. But y’all know infra is actually quite cheap when you run it yourself right?
It’s usually the case with these M&A deals that the profit just never quite makes sense to justify the purchase price, unless you can truly scale up the user base or revenue model. GitHub was already so mature as a solution when they bought it, I don’t know that they could have added that type of value just by slapping a Microsoft logo in the footer.
It used to be, and buying a few servers was a cheap way to get off the cloud (if you can manage them efficiently). But with RAM and other costs these days... I've had to rethink it a lot.
They could do this in a way that lessens external pull requests.
For example, bolting co-pilot on to github, or a Codex in the web kind of thing that gives unlimited check ins.
It's like how Grok Heavy gives the user X premium or whatever. You charge for the tokens and give the unlimted premium access as a bonus. Basically, bundle it.
Microsoft has a financial incentive to push LLMs and also an existential reason since LLM-generated code is incompatible with the GPL.
operating at a loss and non-operational because of outages are very different. If they can't maintain service levels nobody - AI super user or quant, old-fashioned human - will be happy.
Microsoft, who would also have an incentive to extinguish the largest hub for open source development, having already embraced and extended it.
15 years from now, they'll say it was obvious.
What Microsoft models?
> Errors in those services triggered a client-side retry loop that increased traffic during recovery.
The worst outages I've been part of always have some version of this :(
the 'ol thundering herd problem...
Exponential backoff is your friend... too few people use it.
Jittered exponential backoff. You don't want the whole herd to come back at the same time, you have to add timing jitter to the clients.
Possibly dumb/silly question.... Are there any sorts of reverse proxies out there that provide their own layer of jittered/exponential backoff based on patterns? (i.e. requesting IP, cookie, etc.)
I suppose the main reason I think it might be a bad idea, is that it would add complexity to the reverse proxy (i.e. now it's having to track whatever thing is being used and that complexity itself becomes a potential failure point...)
(To be clear, the clients should have their own backoff procedures, but I'm thinking about cases involving naughty clients, which are sometimes a harder problem to correct for...)
I believe envoy has it built in and istio (uses envoy) has different levers for circuit breaking and retries. I’m sure lots of them have it as an option though outside of these.
Don’t forget jitter!
I always add some jitter but never actually had a problem where it would have been relevant. Recently I added it to a project where others also see it (not just a hobby thingy but something at work) and I was wondering if it would look silly, like premature optimisation. I looked on Wikipedia for how established the practice is and it barely gets a sentence... with no reference.
Do you know of a documented instance where it would have helped?
This doesn't answer your question, but I faced an issue where an application had to retry if things failed and I ended up with the "thundering herd" problem and introduced jitter without knowing it was a relatively standard practice.
I felt dirty implementing such a solution (introducing randomness for the sake of randomness is off-putting), but it worked. It wasn't until a while later that I even heard the term "jitter" in this context and realized this was a pretty decent solution for this kind of problem.
Regardless, if you're going to introduce something where adding jitter is appropriate, I'd just just add jitter. It's not premature optimization; it's an essential part of that kind of functionality.
It’s not hard to get started, it’s a case of adding small amounts of randomness.
If you have, say, a long poll then kick off all users due to a deploy or error (or a broadcast message) then you can have a situation where you’ve got a huge clustering of connections at 1 minute, which spreads very slowly out as real life issues give you jitter for free. You can avoid this or at least return to normal much quicker by adding some jitter.
It might happen if all your users back off at the same rate too, if the clustering causes a bunch of errors. Error -> lots reconnect 1 minute after -> fail -> lots reconnect 2, 4…
More likely to occur in cases where there’s a way you can have people all connecting at the same time - synchronisation to a real world event is one case and then connecting again at the same time after.
You have thousands of users connected to a chat via websockets to a small cheap server that can just handle the load. Server has a hiccup, all clients disconnect, server comes back, all clients reconnect at once. Server can’t handle the load.
It’s a fundamental property of Ethernet[1]. Does that count?
[1] https://en.wikipedia.org/wiki/Exponential_backoff#Example
It’s the first thing that came to mind!
Have experienced it, but didn’t document.
Downstream database of our edge serverless platform went down. A tonne of requests failed all at once. Every service in the microservice request path, and the client, had their own retry policy.
Clients all retried at the same time. Retries amplified in our microservice graph (1 request at the front door ended up with like 10s of retries internally as each downstream microservice along the path retried requests). Request queues backed up and couldn’t drain fast enough. Clients all timed out at roughly the same time. All waited the same time. All retried again at the same time.
It was a pulsing thundering herd of many hundreds of thousands of requests at the front door that was amplified by internal retries.
Had to tune up load shedding to 100% after the database outage was mitigated until the backend recovered then tune it down in increments to restore service.
Added jitter to clients and turned off retries on the serverless platform.
Exactly, without jitter the thundering heard problem turns into trying to escape a small island with a small boat and big waves hitting the shore problem. You can never fully recover before you get smashed again.
If you’re talking about internet clients, I think the real world provides sufficient jitter. If you’re talking about a fleet of clients on your 10gbps network, jitter might be useful.
I've had to simulate jitter recently to reproduce a memory spike in a go app using traffic control (tc). have you observed how your app works under jittery network?
Reminds me of this blog post I read yesterday, about Buildkite introducing jitter in their CI agent to reduce synchronisation
https://buildkite.engineering/sleeping-at-scale/
Exponential is also overkill (even with jitter as others have mentioned).
I seem to remember there was a "you failed 5 PIN entries in a row, please wait 500000 seconds before you retry" on Apple phones. So, you probably also want a sensible max... which makes exponential a bit pointless. Just do a basic fixed delay + (large, e.g. 0.5 x the delay) jitter and you'll be fine for most things. You can add a bit of cumulative delay if it's really costly to do retries.
>We have since added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity. We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure.
Crazy.
Are retries bad? These are the sort of reason they make me generally uncomfortable. I appreciate they might be useful in scenarios where connectivity is inherently problematic (e.g. mobile connectivity), but for a super connected and very desktoppy service I'd rather not retry much, if at all. As it obscures it when stuff has genuinely gone wrong, and this worst case scenario is tragic.
I feel like I'm mildly stupid in trying to out retries as heresy but I'm not sure.
https://brooker.co.za/blog/2022/02/28/retries.html
Seems that retries are good when the error is rare, and bad when the error is common. Typically outages have you transitioning from "everything is fine" to "nothing works", so being able detect that transition early is helpful
Retries are good, conditional on having a client-side circuit breaker that stops retries quickly when nothing is working. Otherwise, they are good in good times and bad in bad times.
Retries without (exponential) backoff and/or circuit breakers are almost universally bad, and can even prevent a service from recovering.
Source: decades of operational pain.
This is one of the scenarios where I feel we as engineers should have been more diligent in publicly writing down what techniques have worked in which scenarios and what haven't, and the AI could have gathered decades of operational knowledge and provide proper guidance to architects designing new systems. It's also true that we're witnessing unprecedented levels of scale.
Thundering herds and circuit breakers are extremely well documented and practiced in production. AI absolutely knows about this.
But knowing when to use which strategy and when a simple retry suffices is precisely the type of thing humans will remain to be better at than AI for the foreseeable future.
I think the “thundering herd” problem is pretty extensively documented
isn't that a bomb with a pair of scissors to cut the fuse that could break down under certain conditions?
I feel like they could also hide an issue that might get fixed if there were no retries. Is it slow or is our resource sporadically offline?
Google “thundering herd” and you’ll understand why uncontrolled retries can be / are bad.
Exponential back off retries could hide a real issue, but I would estimate something like 99.99999999% of network retries are resolved within the first 2 attempts.
Not using retries is optimizing for the astronomically rare case, which is better mitigated by other means
I totally agree with you, I think retries are overused, with the exception of operations that are known to be unreliable and can't be improved.
In my experience, errors which go away within a few seconds are quite rare, and are mainly due to flaws which are usually caught in testing.
I think a very careful cost/risk/benefit analysis should be done when adding automatic retries to things. As well as potentially causing cascading failures, it is a degraded user experience when it doesn't succeed.
As a user I would rather see an error straight away than see many seconds of spinning while something silently retries, and THEN an error.
I have the exact opposite view. Way too often, I’ll be presented with an error to the effect of, “something went wrong, please try again” and often the retry works. And I’m left wondering why this machine whose sole purpose is to automate things can’t do that for me automatically.
In particular, networks tend to be a LOT less reliable than the typical developer accounts for. And the failures are very often transient. A case I run into often is doing something with my phone while leaving the house. There’s a window where it still thinks it’s on the WiFi but it’s too far away for it to work anymore. Initiating an action in that window often produces an alert telling me to try again, and trying again a few seconds later almost always works.
The Github outage was about internal clients. Phone apps are a reasonable place to say things are known to be unreliable and can't be fixed. Your IP address changes when you leave the house.
Btw, PWAs added offline capabilities to websites. I hate how the only thing that got used for was these stupid pages that look like you were able to reach the site but it's actually just saying you have no internet, like YouTube.
You're not wrong - https://devblogs.microsoft.com/oldnewthing/20051107-20/?p=33...
I don't like blind retries. It's different if the server or LB knows it's overloaded and asks clients to retry in X seconds.
Oh and this is already assuming the blind retries are randomized exponential backoff. Thought it went without saying but maybe not.
I was using claude tethered via my phone, and would lose signal every now and then as we went through a tunnel. I was glad for how resilient it was its its eventual retries.
It seems like retries are sometimes best left to the human being in front of the screen. Works well enough.
"... these incidents make clear that we must accelerate this work."
It feels like GitHub maybe needs to slow down? 'We must change things faster' is a wild way to start off an eight hour hard-down postmortem.
Do you think the load is going away?
The current infrastructure cannot handle the new load requirements. Either the infrastructure must change, or they must start denying users the ability to use the infrastructure.
Centralized source code hosting is going to end up looking like the three credit bureaus in terms of security. It's only a matter of time before the first big hack, when everyone shrugs and says, "Oh well, everyone's source code leaked lol too big to fail."
Given the jailbreaking behavior of models in Anthropic and OpenAI, as well as Microsoft allowing Copilot access to client data, we should assume our source code on Github is leaked or leakable anyway.
The 'growth in completed actions runs' graph is interesting. I assume the periodic drops are weekends, so intuitively the floor of those drops corresponds more with hobby/personal projects than people at work. It looks like there's a sharp uptick specifically in that floor since July ish.
Distributing across different services wouldn't be a bad idea....
I still can't help but feel a little grateful for what they do across the free side of things. I know it isn't altruism, and I know nobody needs to defend a billion dollar corporation but...
Name another service that does what they do for FREE (and no ads) at this scale. It isn't easy. Wikipedia has probably more usage, but is a simpler endeavor. (except the moderation part, that's just amazing) Open Street map? Smaller and simpler. Internet archive? Again, smaller and simpler. Linux distro mirrors? Again, smaller and simpler than whatever github is doing for free.
“ Name another service that does what they do for FREE (and no ads) at this scale” and is reliable is the question
That's fair!
I'd say kids today are spoiled, but there's no doubt that this has been a rough year for github even if it is understandable circumstances.
Has to be one of the most vague outage summaries of the year
The root cause analysis is separate, but linked to from the blog post: https://www.githubstatus.com/incidents/zkxwbgr0cnmx
It is specific and technical.
Github you can only post you are doing stuff about outages if its actually effective.
The vibes are off.
I don't know where else to ask this but it's killing me. Does anyone know what the hell that GitHub physical CD thing was about? Did anyone in the world get theirs?
Is it me or is all of this essentially "we don't want to show the user anything at all when something breaks?"
And what makes this funny (to me) is that this is a website for developers. I would think that of all the audiences you would target, developers would mind seeing the platform display error messages when things break the least.
Haven't they been migrating to Azure for a few years? How is it still only 58% done... Microslop needs to lay off the focus on AI features and get it done
Is git still the best VCS today? I ask because it seems so much effort in the industry has been invested in making git scale, like Cursor's Origin, or the stories in the past with Facebook's monorepo, but they all seem like bandaids to its intended design.
Centralized decentralized code repos. It feels like an oxymoron.
I think it should be noted that the CTO of GitHub doesn't use his own product. No commits since January 2024: https://github.com/v-fedorov-gh
No side projects? Nothing? Just seems odd.
Maybe he's too busy with leading the engineering side of the company to write code these days?
If even the CEO is vibe coding[1], then the CTO has zero excuse.
[1] - https://www.youtube.com/watch?v=SEZADIErqyw
Can you imagine the flack he'd take if it turns out he'd been moonlighting whilst the GitHub ship is sailing though cat 5 with both the mast and the ship whore on fire?
yeah grinding on side projects, while everything is in flames.
this is fine.
Probably managing and mentoring. I has a boss that wanted to code and be CTO. Just horrible.
Sorry to suggest this but if they charged everyone say $1/mo. it would absolutely help the massive surge from AI coding they seem to have had.
I don't like paying for free stuff but gh certainly worth it.
You are always paying one way or another, I prefer to pay in dollars and not frustration, attention, or privacy.
Unfortunately time and time again, the overwhelming majority of people show that they would rather deal with an unreliable scummy company for "free" than pay $1/mo for a reliable service which treats them with respect :(
OK that "treats them with respect" is certainly an important aspect though. It does not seem like GH is especially great on that one, including listening to its users.
> service which treats them with respect
Which mythical tech company - free or paid - does this?
Surely that's the point. Shed users.
Pay per issue and commit. Buy 1,000 commit credits at a time.
Might force people to review their slop before pushing it.
I would support time based quotas or limits per tier (free, solo, team, etc)
But I'm not going to pay per commit over my monthly plan
I wasn’t being completely serious with my suggestion, but I was thinking of a totally PAYG model. Monthly plans could come with credits, like they already do for Actions.
5X as much code in <2 years. What is all that software?
AI slop
Would it be okay to suspect the recent upsurge in AI agent usage as a possible main cause of this issue?
the retry loop that made the outage worse is just the internet being extra helpful. every client decided the best way to help was to ask again, louder.
What would happen if github was down for like a week?
> Copilot services took longer. Errors in those services triggered a client-side retry loop that increased traffic during recovery.
Let's pretend that the scale traffic is with the number of commit/pr and not self-inflicted with all the copilot eye candy features that were vibe-coded-added to GitHub.
In addition they say that they will continue their migration to azure and that azure is supporting their actions run. But GitHub actions is one of the things that was the most constantly broken without multiple outages recently. So I have the feeling that it proves the point that part of the stability issues is also due to their forced usage of azure.
I fear to ask, how archive.org keeps up to catch all those events for archiving...
The trend doesn't seem sustainable.
AWS CloudWatch has an option to show the trend and what it will be like after x-period.
Doesn't Azure have such options so that engineers can predict to scale better? Seems like engineers are not ready for this per postmortem
The trend line does not tell you what will actually happen at scale, even if you think you're perfectly prepared for the next 10% or 20% growth. As Mike Tyson put it, "everyone has a plan until they get punched in the face".
The problem is there are a class of problems that only appear after you go over the tip of what your system can handle, which are very difficult to predict or model.
Reading this port-mortem / plan shocks me, this doesn't look like a service that has been serving high-throughput services for more than a decade. In fact it is almost like they've barely started. It seems the solution has been capacity, capacity rather than architectural or data changes.
> Our next milestone is an architecture that scales read capacity linearly with the number of readers, enabling unlimited read operations
How do you not have read-replicas / read caches at this scale yet? Which is what I am reading from this statement. You can of course get really far with sharding and whatnot. But at some point it might become worth it to engineer your data into a model that scales better.
> this doesn't look like a service that has been serving high-throughput services for more than a decade. In fact it is almost like they've barely started.
Well that's because in comparison to the absolute flood of traffic brought on by AI, they really haven't been operating on this scale before.
No sorry we messed up your work?
Great read - I'm glad they realize there's work ahead but what I'm missing is: * Paid customers: we know you pay us often a ton of money, and we burn your month on actions during these outages - we'll refund you for the days we spent your money and gave you no value. * Paid customer: We know you put your trust in us, so we'll ensure we have a separate pool of capacity to ensure we can keep that trust. * Paid customer: we'll proactively refund you when we miss our SLA.
What I read from this is: * Scaling is hard, we don't have enough capacity * We give away a shitton of compute for free * I have to talk about Azure not being a steaming pile of poop, otherwise my bonus will get tweaked downward in the next comp cycle.
Notice there's nothing about paid customers, I'll add in what they are missing:
Paid customers: Go F*ck yourself, you don't pays us enough to be an interesting line item compared to windows server.
This. I own a small company with 5 people. I pay Github $250/m. I'm sorry but the narrative of, "look at this burden we have, it's hard to take care of all of this code!" is pretty insulting when I'm paying $50 per person per month to host code and run CI pipelines. If they do not want my money, I'll find a company who does.
With all the software being written on github you'd think we were going though a software rennasance. Where are the results? Is it really just all slop?
Why not identify the lunatic top 1% of free user you know are just abusing the hell out of the system and put severe rate limits across the board for those organizations/accounts?
Why let your entire platform suffer?
Yeah you could probably have a very high free limit that works for 99% of people
With all the outages at GitHub there has to be someone willing to unseat them as the social git repo… how bad does it have to get before folks go elsewhere? Bitbucket and gitlab exist but are pawns compared to a king no?
Ctrl+F "Sorry"
No results.
Cool
As I mentioned before (https://news.ycombinator.com/item?id=49333107), they can mitigate these issues with limits, even for failure cascades. There should've been an all-hands-on-deck feature freeze 6 months ago to implement the limits needed. That clearly didn't happen.
I think it's because their leadership actually doesn't care that it goes down. A weekly outage is now an accepted cost of continuing to allow unlimited free access with infrastructure that cannot possibly handle the load. As a result, everyone is looking at their GitHub Enterprise bills and cost of stopped work, calculating how much they'd save by self-hosting.
"We are committed to fixing these problems, as long as it doesn't involve buying things other than AI computers, hiring humans, or using non-Microsoft products."
Calling Azure the solution to this problem when it is in fact the source of most of these problems is just fantastic doublespeak.
Github is ripe for disruption and I hope it is disrupted soon.
> We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure.
And from the RCA [1]:
> The immediate cause of the failure was network saturation on load balancers in Central US due to a new peak in traffic.
[1]: https://www.githubstatus.com/incidents/zkxwbgr0cnmx
"While accelerating our migration to Azure," meaning, they will only solve problems if it helps them also use Azure more.
It is unbelivable that aload of 2.8b commits was totally fine, and a load of 2.9b was a sitewide outage, unless they have no reporting or their tooling is completely incompetent. If things can fall apart so easily, throwing more capacity at the problem won't fix it.
You’re torturing your own logic to make Azure the villain here. And it also sounds like you lack experience with capacity exhaustion. Things fail slowly, then suddenly.
There's always a cliff, this part is fine. You sometimes know the cliff but often do not.
I’m firmly in the camp of “something stinks at GitHub” but
> It is unbelivable that aload of 2.8b commits was totally fine, and a load of 2.9b was a sitewide outage
In my experience, there are hard thresholds that get passed that expose hidden bottlenecks like this. A previous system I worked on we had absolutely loads of headroom by all of our measured metrics, but one day we filled a cache because the value hadn’t been tweaked in recent memory. Plenty of space on disk and in memory, but all of a sudden we went from a very high cache hit rate to a very low cache hit rate, and everything ground to a halt.
This absolutely can happen in large systems. If some part of the system is at capacity, then slightly increasing the load can cause it to fall behind and start accumulating a backlog.
These backlogs can cause clients to make more retries, exacerbating the problem. Potentially further cascading through the system.
I believe their point is that "system is at capacity" is something they ought to start fixing before the capacity is exceeded
But then people like OP will claim that the capacity concerns are a lie manufactured to support an unjustified move to Azure.
Sure. But you might not even be realizing that something is just at the cusp if the load is spiky enough.
The art of large system design is to identify and avoid these kinds of chokepoints. And when something happens, propagate the "backpressure" up the stack to avoid queuing.
AWS got a fair share of similar outages, so the newer SDKs now try to not exacerbate these kinds of issues: https://docs.aws.amazon.com/sdkref/latest/guide/feature-retr...
The original AWS EBS outage is probably the canonical example: https://aws.amazon.com/message/65648/
>"While accelerating our migration to Azure," meaning, they will only solve problems if it helps them also use Azure more.
Look, I hate Microslop as much as anyone but you'd have to purposely misinterpret TFA in order to arrive at this interpretation. C'mon.
Ok, but there's no universe where a major Microsoft-owned property is not being forced to run on Azure. Just like AWS pushing to get off Oracle back in the day. It would be career-destroying to suggest otherwise regardless of technical merit (and tbf, no infrastructure is bulletproof, unless you want to port GitHub to z/OS on mainframe)
LinkedIn gave up after four years of trying: https://www.cnbc.com/amp/2023/12/14/linkedin-shelved-plan-to...
Azure just has very poor performance and reliability characteristics. It’s a particularly bad migration target for a colo-based company that mainly runs on owned hardware (such as GitHub or LinkedIn). Requires much larger architecture changes than (say) a company coming from AWS.
I'm betting on Tangled and Codeberg. Tangled has a better press and in general is a dark horse, Codeberg has the "brand" and some network effects from projects that moved to there. (famously, Zig.) I heard that Sourcehut is having a moment as well, and I love the idea of email-based workflow and not having to have an account to contribute to someone's project hosted there, but I'm not maintaining anything worthwhile paying the $4/mo sub.
What if it was $2?
that is more manageable but c'mon I can't even keep Google One 100GB up on a consistent basis, that's how poor I am. self-hosting would be a far better option because apparently I find enough people to provide free Hetzner VPSes and stuff as long as I can sell this as mutually beneficial.
for context, I would GLADLY move there my Neovim plugin. all it does is brings the current jj message into your editor and lets you integrate it with a status bar (or anything in nvim, really). that would be a decent measure against drive-by slop contributions, and I'd accept contribs over private github mirror from those who I know but can't bother setting up git mail
EDIT: TIL that one can host SourceHut themselves. discoverability may still be a problem (sr.ht just ranks higher in search engines) but 1) fixable with github mirror that points to sourcehut instance as a canonical development platform, 2) it's moderately easy to sync contributions between tangled and sourcehut, so tangled is also an option
EDIT 2: the email part would be PITA, so $4/mo is attractive on that background
Oracle has a free tier that you can self host a git server on, if that's what you're looking for.
The Azure horror stories are on this blog post and HN discussion.
https://news.ycombinator.com/item?id=47616242
> Github is ripe for disruption and I hope it is disrupted soon.
It's an expensive, low revenue generating site.
There are, and have always been, competitors, including "host it all yourself" solutions, but nothing has really stuck.
How is it "ripe" for disruption?
They had $1b revenue in 2023 and now probably more than $2b in revenue... do you have cost figures showing what their expenses are?
> We have since added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity. We installed as much hardware as available power allowed in our existing data centers while accelerating our migration to Azure.
That can't be cheap.
A server box now has around 256 CPU cores. So that's about 12000 servers. If each one is $10k that's $120 million. Not a lot compared to Github's income.
$10,000 is only enough for CPU cost (2x AMD EPYC 9754). The rest of the servers (mainboard, RAM, storage, power supply, network card, rack, cooling, etc.) can easily triple or quadruple the cost.
Yup. Still, it's less than their annual income by several times.
Does that $10k server not need RAM?
If parent commenter is off by an order of magnitude in their costs, their point still stands.
$1.2 billion of costs on revenue of $1-$2b certainly seems like a big concern.
They do not throw away the servers every year..
Microsoft don't release the costs as you know, but
Compute and Storage for Free Tiers: Hosting code for over 150 million developers and processing over 2 billion GitHub Actions (CI/CD) workflows a month requires astronomical server power and data storage. The "Free" tier is a massive cost sink that Microsoft treats as a loss-leader marketing expense
Let me know when you understand how that's not free.
If you're a big company, you can afford having one engineer spend one or two days per year to maintain your self-hosted GitLab or Forgejo. On top of better reliability than GitHub, you'll get the additional bonus that your source code won't accidentally leak through being in Copilot's training set.
If you're a hobbyist, Codeberg is great, has a nice community and automatically shields you from slop contributions.
Speaking from experience, it cost mW about a week or two per year to maintain GitLab for the startup I worked at.
My personal GitLab on the other hand really does take only a day or two per year.
That said, a week or two per year is just what it costs to maintain any one thing period. I spent about that much time maintaining PCs in the office, or my personal proxmox setup. It's not onerous at all.
GitLab is super bloated and a little sucky to admin, but it's not too bad all things considered. I'm admin in my new job's GitHub org and it sucks a whole lot more to maintain.
The issue with these systems is that they lack Github's sophistication for issue tracking, knowledge transfer, and automation. I think Gitlab is a mature product in its own space and unlikey to change, for instance, at this point.
Codeberg also has the issue of having a political stance which means they will not accept just anyone's use of the platform. That is absolutely their right and I have no issue with it, but it's unattractive to me - as someone who agrees with most of their current politics - because the day they decide they don't like me, I'm screwed.
I never found GitHub's systems for issue tracking to be all that great. Cross-repository issues and development plans are hard to track within a git host. I've always used an external panning and issue tracking tool, mostly Linear, and it works really well. GitLab's Linear integration is excellent, FWIW.
I've actually worked with a couple of companies who do use GitHub for their code, and they all use Linear in addition to GitHub.
I understand the concern you're talking about wrt. Codeberg, but I wouldn't view it as a significantly bigger risk than anything else. Any platform can suddenly decide that your project is against ToS (GitHub will absolutely not accept just anyone's use of their platform either) and Codeberg introducing some rules recently doesn't, in my mind, drastically increase the risk of a dramatic ToS change in the future. But we all have to make our own risk evaluations and I won't judge yours. Luckily, moving between Git hosts isn't that difficult; setting up CI again and losing merge request history does suck but it's not the end of the world, unlike something like, say, losing your AWS/GCP/whatever account.
"sophistication" seems like a strange way to describe GitHub to me - I've found in every individual aspect (code browsing, issue tracking, code review, package management, etc), it's the worst out of all the systems I use regularly... But it's good _enough_ for most people, and it has all those features in one place, which is more convenient than wrangling 10-15 high quality but disconnected systems
Gitlab has the benefit of having very little traffic, both free and paid. Their limits are still way above the current usage so less likely to be an issue
Worth mentioning GitLab's paid enterprise offering are more expensive than GitHub's, on a per-seat basis.
Lots of companies moved because it was cheap, but it's not anymore. Ironic that companies might choose to migrate to them now for stability, rather than price.
Dude no one uses github tracking for anything serious, come on. The only thing github has over gitea/forgejo is discussions. That's the only real social "innovation" github has contributed to open source development and it's just a shitty tacked on forum.
Also for accuracy, Codeberg has a pro-human and anti-corporation stance. Both of which are definitely en vogue at the moment.
Much better than GitHub's pro slop sentiment, which is doing nothing but destroy their reputation.
This is a really good post.
I said in another thread that they can't blame increased demand for these outages, but the demand growth is genuinely insane for a company already operating at huge scale.
I guess we'll have to wait and see if they deliver now, but it seems like they're taking it seriously at least.
someone needs to build a open source aws
Use less AI slop coding
Related recently:
GitHub has alternatives, but no replacement
https://news.ycombinator.com/item?id=49135365
Why developers are ditching GitHub for Codeberg and self-hosting alternatives
https://news.ycombinator.com/item?id=48842611
and new entry:
Cursor Origin Code Hosting
https://news.ycombinator.com/item?id=49334209
We need to have a package of FLOSsoftware that you could run on the cloud of your choice that offers most of what GitHub does (niceties on top of Git) without the centralization.
GitLab was close last I remember but there was some sort of enterprise tier when I tried hosting stuff on a local server years ago. I want true FLOSS, not another SaaS equivalent of the coke dealer giving clients the good uncut stuff when they're just starting out only to sell crap when they're addicted.
https://forgejo.org/ promises to be this, have only lightly used it on https://codeberg.org/ but it seems nice?
Forgejo is pretty neat. Their CI story is sad because it's based on act and it lacks features like GH Apps so service accounts are not possible (using a user account as service is barf).
I self-host it and its pretty easy to have uptime higher than github when you have 3 users total.
Absolutely do not recommend using GitLab.
"Forgejo is a self-hosted lightweight software forge"
That says absolutely nothing. The "What is Forgejo?" question is unanswered and instead you get a lot of words about their values, their inclusivity, etc. And the next thing in the docs is how to install it. It's ridiculous.
I still don't know what it is or what it does.
“Software forge” is an established[1] term by this point: a piece of software providing a full set of features for collaborative development, usually at least code hosting with a web interface, tickets, and webpage hosting, and these days often also code review and integrated CI or at least the possibility of integrating CI. It’s admittedly squishy but in the same way “IDE” is squishy, which is to say it’s still well-defined enough to be useful.
[1] https://en.wikipedia.org/wiki/Forge_(software)
> a package of FLOSsoftware that you could run on the cloud of your choice that offers most of what GitHub does (niceties on top of Git) without the centralization.
You're in luck, GP comment described it for you.
Forgejo > The name of the software
self-hosted > You install it on your server
lightweight > It does not consume a lot of resources (cpu, disk, ram)
software forge > offers tools that help with creating software collaboratively (repository hosting, change request management, wiki for docs,…)
Have you looked into Forgejo?
I'm particularly fond of the concepts within git-appraise, gits back to the federated foundations
https://github.com/google/git-appraise (unmaintained)
Exponential growth. No company could handle that without some issues. Good luck to them. And for those who cannot tolerate this, there are many self hosted options.
And another outage. [0] Looking forward to the subsequent post-mortem on that one.
You might want to not go all in on GitHub anymore since it is very unstable to use. A self-hosted instance would have a far better uptime than GitHub over the years.
6 years ahead [1] on not going all in an centralizing everything on GitHub.
[0] https://www.githubstatus.com/incidents/bhbcjn4n3jzp
[1] https://news.ycombinator.com/item?id=22867803
Almost 8 hours of downtime across all core workflows, and the word "sorry" or "apologize" appears nowhere in this post.
"If you were trying to ship software that day, we let you down" is classic corporate non-apology speak.
I’m done.
i am confident that if "sorry" appeared, someone would make a comment about "hollow apologies" or similar.
im sorry u feel this way
thats what i liked about it. its fact and action oriented. what does a "sorry" buy you that the "we let you down" doesn't.
It's funny, I bet you could take any software dev and blind AB test a page written by a corporate manager and a page written by an engineer.
Here's something an engineer writes, loaded with facts:
"I got to the office and we had a huge panic going on, I immediately called our IT in US-2West and they reported on cascading box failures, I checked our load balancer via remote admin and indeed it was failing to. I called my IT managers and learned we had hard resetting in progress for the past 20 minutes with minimal impact on recovery."
Totally missing from the article.
Bye Felicia
well written
Github down, no hard drives available, no memory available, thanks AI!
Seems like we are headed for Tech Gridlock.
This stuff is good! This is what a booming economy looks like. There are people out there competing with you for resources because they have cool ideas they want to implement.
Or at least they asked the AI to come up with cool ideas, which is even more interesting. It's exciting watching the world transition away from humanity being in the driver's seat!
Layoffs by the 10s of thousands, food prices out of control, people barely able to afford gas. At least some tech bros can launch their 50th B2B SaaS. I didn't realize a booming economy sucked so much.
The exciting thing about AI is precisely that it'll let software move beyond Yet Another B2B SaaS and into doing useful things in the real world. I regularly ride in driverless cars! That was the stuff of science fiction when I was a kid.
If you're worried about food prices, you should be happy that robots will make agriculture less labor-intensive and bring prices down.
probably worth asking when those prices will come down.
What they can implement is to slowdown the commit rate, rate limt or just queue-up messages not to overburden their downstream service.
I don't think GH has any of those, but just keep scaling, but that scaling failed.
Just bad architectural decisions from the postmortem.
--
It will only get worse due to AIs spawning massive commits, and they don't have unlimited cloud resource.
They can scale but not scalable in terms of effort, resources, and $
How would any of what you're saying help with this?
> The immediate cause of the failure was network saturation on load balancers in Central US due to a new peak in traffic. Originally this was caused by an Istio sidecar pod reaching its concurrency limits and failing to auto scale correctly because of a misconfigured policy that watched host service but not sidecar limits. One failure cascaded to more and eventually four HAProxy nodes exhausted their flow limits, degrading the gateway auth path and causing widespread authentication latency and failures. The problem was worsened by optimistic retry logic which overloaded internal load balancers. Pausing HAProxy on those nodes simultaneously produced immediate broad recovery.
load balancer failure? rate limit woudl address concurrency limits? throttle or queue up messages. auto-scale failed cause was misconfiguration policy, which i admit cannot be handled by my suggestions. The cascade? it's downstream service degradation, which I mentione should have had been prevented with queues. One of the jobs that queues/kafka solve is to prevent these downstream outages.
If your LB is down, you're just kind of screwed. You can't enqueue things if requests aren't getting through at all. Same deal with authn/authz issues, which they also had. If you can't answer the question "is this message allowed to be added to the queue" you can't enqueue stuff.
GitHub does use queueing for all kinds of stuff internally, though, because they're not morons.
They should rewrite their Ruby code to a performant language.
i wanna vibecode a replacement for git and call it jit
> What we have done and what comes next
"You've seen what we've done. The August 21st outage comes next. See you then!"
Here's Vladimir Fedorov's GitHub contribution graph, as linked to as the author of this post:
https://imgur.com/a/zIbT0Gi
It shows zero contributions in the past year, on this account. This is a huge, huge red flag.
I strongly disagree. GitHub, a year ago, acknowledged the fundamental problems and began work on them. We all agree with the diagnosis and strategy: stop building new things, bring stability. Why would whether the CTO codes have any bearing on the correctness of this strategy? GitHub’s problem isn’t that leadership don’t understand the product, or that they don’t know what they should be doing, it’s that they’re battling unprecedented demand. If it was a disconnect between users and leadership on what matters, sure, a CTO who doesn’t use the product would be notable, but that isn’t the problem. And that’s all assuming he doesn’t actually use the product, maybe his privacy settings hide private commits.
Interesting - There's a couple of things that I disagree with here, but I do think this resonates: "We all agree with the diagnosis and strategy: stop building new things, bring stability."
Where I have a problem with the positioning of their GitHub profile is, he's the CTO of GitHub, arguably the defacto standard for open-source version control systems. His GitHub profile is linked to as the author for the post, and his GitHub profile simply tells me: "this guy doesn't code."
I don't care if this guy doesn't work on GitHub itself, I hardly would expect that, but IMO, any CTO of a company like GitHub should eat, breathe, and sleep code. He might, but his profile, which is being published as if it means anything, tells me he doesn't.
Mine would look the same if you didn't have access to the private repositories I contribute to at work.
Don't contributions to private repositories simply show as: "N contributions in private repositories"?
Here's me: https://github.com/ryanisnan
In other words, I think his private contributions should still manifest on the contribution graph. And for being the CTO of an organization like GitHub, with no open-source contributions... Not a great look.
you have to opt in to private contributions being visible like that