Rendered at 07:09:25 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
afc 49 minutes ago [-]
> Neither outage was caused by a code or configuration change. Both incidents were capacity failures at their core. We failed to scale critical components before demand exceeded their capacity.
This is the wrong way to think about this because there's no such thing as infinite capacity. A large distributed system will be simultaneously mostly idle and (in some subcomponents) overloaded. The root cause is not "a component didn't have enough capacity (because of auto scaling failures)", but rather "this complex system collapses (rather than degrade gracefully) when demand exceeds capacity".
When components reach capacity limits, the excess traffic of the lowest priority should be rejected. Rejected traffic should not be retried — in fact, not only should clients not retry these errors, these errors should cause client-side throttling. Traffic isolation should be applied — if the cause of the overload is a single client/customer system, no other system should be affected.
Nearly a decade ago I wrote about some of the techniques we applied at Google to implement these protections: https://sre.google/sre-book/handling-overload/ Most other large internet services have since copied them, afaik.
eckesicle 6 minutes ago [-]
This is an excellent book and its lessons saved my bacon many times!
As it happens I have a hardcopy of this book (along with "Seeking SRE" and the "SRE Workbook") that I am giving away (because of a move). If you want a hardcopy then email me your UK address I will be happy to post them to your for free.
I tried putting them on the street in a little box but surprisingly none of my neighbours grabbed any of my software books. :)
blakesterz 11 hours ago [-]
"Since April, monthly commits have grown from 1.4 billion to 2.9 billion. "
Wow, that is some incredible growth in a really short time.
m4rtink 4 hours ago [-]
So much more stuff and growing- what it is actually useful for ? Are we getting actually more done than with previous volumes or is it just all wasted energy?
brookst 3 hours ago [-]
I’m getting a lot more done. Hobby projects that languished for years are coming along great, at quality and depth I could never have found time for before.
yread 1 hours ago [-]
Other projects get unmaintained with maintainers burnt out by a torrent of vulberability reports
fsloth 1 hours ago [-]
This I don't understand.
If it's not your job, then just ignore the reports.
If it's actually critical, someone will put money on the table and then it's a business. And then it's about scheduling and resourcing - also should not burn anyone out.
Just because many people have false sense of entitlement as soon as they get a free offering, it does not mean anyone needs to accommodate them.
okeuro49 17 minutes ago [-]
> If it's not your job, then just ignore the reports.
If you have a highly conscientious personality, this is easier said than done.
xeromal 2 hours ago [-]
Same. Helping family out when I generally was too tired to do it earlier. They're all very happy too
croes 2 hours ago [-]
Are they happy about the circumstances of AI too?
Higher resource consumption and the set back in CO2 reduction?
A link to a YouTube video without context e.g. summary of findings, primary author/creators, and primary citations, methodology, and so on is a next to useless for making a point. For all we know you’re linking to a crackpot or an industry sock puppet and I don’t care to “watch” any of what can potentially be a dubious video or worse a malicious video. It is your job as the linker to convince me the video is worth even one iota of my time.
On the other hand recent papers highlight the validity of concern/suspicion:
> This systematic review demonstrates that the environmental footprint of artificial intelligence is a structural and increasingly consequential challenge, shaped by interdependent decisions across algorithms, software pipelines, hardware infrastructures, and deployment contexts. The synthesized evidence shows that energy consumption and carbon emissions associated with AI systems are highly variable, context-dependent, and often underestimated — Beyond Efficiency: A Systematic Review of Energy Consumption and Carbon Footprint Across the AI Lifecycle (published in “Sustainability” an international, peer-reviewed, open-access journal)
https://www.mdpi.com/2071-1050/18/3/1359
bch 49 minutes ago [-]
> raised heat is a kind of pollution
> water is not unlimited
> you don't want to release a bunch of acid into a river
> I know next to nothing about this
> I know basically nothing
> corn is one of the thirstiest major crops grown in the US
What is this rant supposed to inform? Whats wrong with OP being concerned about the costs of operating a DC?
user43928 16 minutes ago [-]
Nobody is concerned about the costs and environmental impact of data centers.
When someone in a discussion about the benefits of AI goes "did you think about the environment?!", it's always performative.
The real motivation is disliking AI itself or doubt about the government's ability to offset the labor market impact. Discussions that start with feigned concerns being raised are nearly always going to be unproductive.
throwawayqqq11 57 minutes ago [-]
GP wasnt mentioning water consumption.
croes 48 minutes ago [-]
What make you think I‘m talking about water consumption?
The construction of data centers needs resources and also creates more the CO2.
The energy for these data centers is often created through fossil fuels which also creates additional CO2
What do you think why Google and MS scrapped their CO2 reduction targets
CrimsonRain 2 hours ago [-]
[flagged]
nullsanity 1 hours ago [-]
[dead]
fsloth 1 hours ago [-]
Same!
maciejgryka 58 minutes ago [-]
That’s like asking whether fuel consumption was productive or leisure as the number of cars on the road increased. It’s both! I don’t think you can separate one from the other in any reasonable way.
ozgung 1 hours ago [-]
Has anyone noticed an increase in the quality, performance or capabilities of the software they use?
teiferer 29 minutes ago [-]
Only in software that is used to make other software. So we're all just patting ourselves on the back within our bubble.
What I have noticed an increase though is in demands and pressure to deliver.
compass_copium 4 hours ago [-]
You already know the answer to that question
gabriel-uribe 2 hours ago [-]
More done + more leisure.
mikae1 2 hours ago [-]
That's how it's sold, but have you heard about any major tech company that sends their worker home when they've achieved what they used to achieve pre-AI?
EDIT: Instead of simply down-voting, you're welcome to name examples that proves me wrong ;)
user43928 5 minutes ago [-]
The only way that you can translate productivity gains into more free time in a salaried position is by working remotely. Seems obvious, no?
0x696C6961 1 hours ago [-]
This is anecdotal, but I know that a lot of my coworkers and coasting and putting up one AI generated PR per day which they've hardly even self reviewed.
teiferer 28 minutes ago [-]
In a good company that will come back to bite them next performance review.
So, if it doesn't then you learned something about your workplace (and it's not good).
2 hours ago [-]
croes 2 hours ago [-]
Is it used afterwards or done and forgotten?
parapsychic 3 hours ago [-]
To some extent we are getting more things done as well. In my company (mid-sized startup), they're making us push features every other day now as opposed to maybe 1-2 features per person per sprint. Back when I joined, things were a lot slower. Today, they expect freshers to push new features on day one.
But ofc, slop has increased a lot more as well.
thisOtterBeGood 2 hours ago [-]
That's very fast. Feels like you cannot really review this code so it's all just "working" AI code with few railguards and few human supervision?
throwawayqqq11 52 minutes ago [-]
Jumping on the great asymmetry of output between humans and llms, yet still being responsible for the product is pure kafka.
croes 2 hours ago [-]
And how many of that features are actually used?
How long do they last until the get replaced by the next feature?
CrimsonRain 2 hours ago [-]
I built a travel companion app including planning full itinerary in two hours that would have taken a few weeks of full time work and then added many more features in less time than those features would take in just meetings in a real office let alone build/test them.
I'm sure I'm not alone. While AI luddites are spreading FUD, real builders are building heads down.
0x696C6961 1 hours ago [-]
Lol you don't need an app for this. My (barista) gf did the same thing by just telling Claude to create pages in notion.
MattRix 3 hours ago [-]
I have some big issues with this technology and the companies behind it, but I know of quite a few people personally who were not previously coders but have now been able to use LLMs to make their own custom software, solving real problems they had.
fmbb 1 hours ago [-]
Do you believe this is a significant part of the increased GutHub traffic, people’s personal software?
rob74 55 minutes ago [-]
Are non-coders these days aware that they should use version control (and push their code to GitHub)? Or does their agent helpfully suggest setting up a GitHub repo?
colechristensen 3 hours ago [-]
One of the things I've done is create an entire fully functional GitHub alternative that does more of what I want and hosts all of my other projects, so yes I at least am getting considerably more done.
pseudosavant 8 hours ago [-]
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.
pseudosavant 4 hours ago [-]
It’s funny how the quality of the average commit message has gone up, now that we rarely read or write them directly anymore.
asdfsa32 3 hours ago [-]
You may be confusing articulate and confident with useful and accurate.
fartfeatures 3 hours ago [-]
They really aren't. AI commit messages are much more thorough and correct than some of the stuff I've seen humans do over the years e.g. Fix, Fixup, Fixed some Stuff, Should work now, Definitely should work now etc etc etc.
realusername 2 hours ago [-]
I definitely prefer a "fixup" to a three paragraph meaningless word soup which doesn't cover why the commit is there either
kqp 2 hours ago [-]
If you can’t tell how this is a non sequitur then it’s very likely you, too, confuse articulate and confident with useful and accurate.
amarshall 4 hours ago [-]
Has it? Most of the LLM-generated commit messages and PR descriptions I read are needlessly verbose and miss the point: elucidating the why of a change rather than the what. If I actually pose a question based on them the author often tells me “yea that was some AI generated nonsense, I rewrote it now”.
AI (coderabbit, claude, github actions) review the PR, AI (robobun) applies the fixes.
Some AI back and forth.
A human finally merges the PR.
Not gonna lie, it's kind of beautiful.
bigiain 2 hours ago [-]
Some guy, profiling his linux distro, wonders why ssh connections are a few hundred milliseconds slower than expected, finds there PR introduced and RCE backdoor and p0wns the whole project.
CrimsonRain 2 hours ago [-]
As it should be if not more. What's wrong with it?
mikaeluman 33 minutes ago [-]
Wow...
I am currently using bun, but may have to switch. I can't see how this can possibly turn out well in the long run...
And...? It just shows how active and big the project is.
tecleandor 7 hours ago [-]
And 5K PRs. I'm crying.
8cvor6j844qw_d6 7 hours ago [-]
> 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.
mananaysiempre 7 hours ago [-]
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.
m4rtink 4 hours ago [-]
You never could scale tulip buds so quickly - progress! ;-)
steve_adams_86 9 hours ago [-]
Strange to think they are probably triaged by LLMs at this point
danudey 8 hours ago [-]
AI finding issues in code and reporting them so that an AI can review and triage them for another AI to fix.
collinmanderson 5 hours ago [-]
That seems to be what's happening. Like 2-4 bots talking to each other, then Jarred Sumner just does the final merge with little comment.
github-actions: "If you need a paragraph-long comment to justify why the workaround is OK, the code is wrong — fix the code"
robobun: "The ordering is load-bearing: reclaiming before this block made is_dead_request true and hung a parked textStream read (caught by body.test.ts in CI). The comment pins that constraint."
Ah, well, if something is load-bearing, then I guess that settles it. Need a comment to pin that constraint, in case a read is parked. These are words that normal humans commonly use in these ways.
(Always striking how much Claude obsesses over the minutiae of method contracts and side effects, exhaustively documenting them in comments. It’s much happier figuring out how to reorder some method calls with nonobvious side effects so the code works than it is refactoring them not to do unexpected things!)
eszed 8 hours ago [-]
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?
fg137 7 hours ago [-]
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.
CrimsonRain 2 hours ago [-]
Why it doesn't work? It is working for me. It is working for bun. It is working for others who actually embraces it and puts in the work to get it working.
SaucyWrong 1 hours ago [-]
I recognize your username from other comment threads and would classify you as a bun fanatic, but even so, I’d hold off on saying, “it’s working for bun,” until 1.4.0 has been out of canary for, like, more than 24 hours. Most real users haven’t onboarded to it yet.
tonyhart7 1 hours ago [-]
sadly someone didn't have free unlimited Fable and Opus like Bun team does
Let's just say my dream does not involve babysitting some robot
tymscar 7 hours ago [-]
Who promised it?
markus_zhang 5 hours ago [-]
Not my dream…
8 hours ago [-]
brookst 11 hours ago [-]
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.
xyzsparetimexyz 11 hours ago [-]
wow. they should really institute a maximum amount of individual pushes per-month per-user.
consumer451 10 hours ago [-]
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.
Macha 10 hours ago [-]
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.
b112 9 hours ago [-]
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...
consumer451 7 hours ago [-]
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.
8 hours ago [-]
fragmede 8 hours ago [-]
It's not a red herring, every commit necessitates a database hit.
dham 7 hours ago [-]
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.
consumer451 4 hours ago [-]
Me personally, I would like to own the world's code.
The richest man in the world is interested in this dataset as well.
lenkite 3 hours ago [-]
I don't think anyone would love to own the world's AI slop. The capex and revenue expenditure would be too high for any ROI.
saghm 9 hours ago [-]
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!
bragr 9 hours ago [-]
I remember when you had to pay for private repos in the first place.
riffraff 9 hours ago [-]
Initially there were no private repos for free users at all, it was a selling point for bitbucket that they offered that.
slashdave 7 hours ago [-]
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?
eudamoniac 5 hours ago [-]
Uh, pay money for the service you're using constantly?
xienze 10 hours ago [-]
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.
Avicebron 10 hours ago [-]
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.
10 hours ago [-]
2 hours ago [-]
flohofwoe 38 minutes ago [-]
It's like cancer growth though, not the 'good' kind of growth ;) E.g. I doubt that the number of Github users has doubled in that month too. Github should probably introduce daily commit- and merge-limits that slow down excessive clanker activity, but are high enough that a human doesn't notice. Alternative put users with excessive resource usage on their own 'sub-infrastructure' so that when this is overloaded, the regular users are not affected by the outage.
mawadev 7 hours ago [-]
I would give the growth hacker on their team a big raise, these KPIs are incredible
chanux 1 hours ago [-]
Oh the productivity increase.
I feel it in my fingers. I feel it in my veins.
tremon 9 hours ago [-]
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?
kylecazar 9 hours ago [-]
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.
_heimdall 7 hours ago [-]
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.
ferngodfather 8 hours ago [-]
But they can't process the commit until I push it?
dcrazy 8 hours ago [-]
A push containing 100 commits is more expensive than a push containing 1 commit.
blitzar 8 hours ago [-]
But is it 100x more expensive?
Groxx 8 hours ago [-]
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.
lukevp 7 hours ago [-]
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.
Groxx 7 hours ago [-]
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.
richardwhiuk 40 minutes ago [-]
Things like password scanning have to look per object uploaded
johndough 9 hours ago [-]
Bigger numbers sound more impressive.
"Our billion-dollar infrastructure crumbles under a tremendous flood of 50 PRs per second" would just sound embarrassing.
recursive 9 hours ago [-]
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.
Brian_K_White 9 hours ago [-]
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.
orf 9 hours ago [-]
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.
jeremyjh 8 hours ago [-]
> 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.
orf 8 hours ago [-]
> 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.
jeremyjh 8 hours ago [-]
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.
charrondev 7 hours ago [-]
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.
jeremyjh 48 minutes ago [-]
You are right about secret scanning, but its worth noting that is only enabled by default on public repositories. It is an extra paid feature for organizations on a teams or enterprise subscription, and isn't available at all for individual owned repositories outside of an enterprise subscription.
And yes, I agree there is indexing of commits, but that is a batch insert from a log.
meerita 8 hours ago [-]
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.
leptons 9 hours ago [-]
>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.
ninkendo 7 hours ago [-]
> 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.
Brian_K_White 6 hours ago [-]
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)
"We have since added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity"
meerita 8 hours ago [-]
It's almost double. If you have scaling prepared, it should be linear, but I doubt they've prepared for this.
brazukadev 8 hours ago [-]
they are/were in the middle of a migration
VCFundedGenYer 10 hours ago [-]
Not really. It's AI commits. Not quality commits.
aaronvg 10 hours ago [-]
it doesn't matter though, commits create load in their system
jazzyjackson 9 hours ago [-]
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 ?
8 hours ago [-]
brookst 3 hours ago [-]
Because human commits ar necessarily quality?
john_strinlai 9 hours ago [-]
the infrastructure does not care about the quality of the commits, just that a commit happened.
jvwww 7 hours ago [-]
A lot of human commits are low quality
whatsThisBtn4 9 hours ago [-]
[flagged]
sgarland 8 hours ago [-]
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.
7 hours ago [-]
whatsThisBtn4 8 hours ago [-]
Coding is dead.
fatata123 7 hours ago [-]
[dead]
nullsanity 1 hours ago [-]
[dead]
p-e-w 7 hours ago [-]
> 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…”
wasting_time 6 hours ago [-]
It will be interesting to see if LLM can push beyond the intelligence embedded in language.
General intelligence may still be a ways off.
nozzlegear 4 hours ago [-]
General intelligence is a convenient myth perpetuated by the marketing departments of AI corpos to help further their pursuit of regulatory capture. Don't fall for it.
27183 4 hours ago [-]
> That knowledge will be worthless 12-18 months from now when AI does everything better than you, including “understanding”.
...what? Seriously though. What grand insight into the arc of AI development do you have? Where are you getting this from? Cite your sources. Show your analysis.
Charitably, I would ask "are you high?".. If you're suffering acute psychosis from mind altering chemicals then we merely have to wait for the effects to wear off and you'll likely recover. If not, then I'm very sorry. Your road ahead is a rough one.
ex-aws-dude 9 hours ago [-]
I mean if I set up a for loop spamming my own SAAS it would be incredible growth too
toephu2 10 hours ago [-]
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.
seizethecheese 10 hours ago [-]
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).
shimman 10 hours ago [-]
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?
seizethecheese 10 hours ago [-]
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.)
shimman 4 hours ago [-]
LLM companies are already wildly unprofitable. Who ever wants to do this can be my guest, but please let's tax them enough so that we can get something positive out of the stupidity like free public school lunches for children or universal childcare.
Aachen 10 hours ago [-]
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
seizethecheese 9 hours ago [-]
> 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.
airstrike 10 hours ago [-]
It's an impressively large quantity of X, not an impressively good X.
Aachen 7 hours ago [-]
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
gamegod 9 hours ago [-]
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.
whatsThisBtn4 9 hours ago [-]
I don't know how to delete things.
skydhash 9 hours ago [-]
And what would be the expected result (other than spending $20 a month)?
whatsThisBtn4 8 hours ago [-]
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.
kraken_cult 9 hours ago [-]
Automated slop?
wegwerper 9 hours ago [-]
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.
fg137 7 hours ago [-]
Should use on premises.
fragmede 8 hours ago [-]
They do. Talk to your account representative for the alternate domain name to hit.
mikert89 10 hours ago [-]
alot of distributed systems in big companies grow at this rate, its not exponential, its mundane
tracerbulletx 10 hours ago [-]
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.
mikert89 9 hours ago [-]
AWS saw this growth every year for two decades, hyper growth tech sees it all the time
jeremyjh 8 hours ago [-]
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.
mikert89 8 hours ago [-]
im not buying that github is a unique engineering problem, harder than the rest of hyperscalars.
jeremyjh 8 hours ago [-]
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.
sgarland 8 hours ago [-]
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.
jeremyjh 7 hours ago [-]
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.
mikert89 8 hours ago [-]
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
jeremyjh 8 hours ago [-]
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.
mikert89 7 hours ago [-]
its probably happened on half the core teams, idk what you want me to say, it sounds like you dont have alot of experience
antiframe 5 hours ago [-]
Don't dodge the question and attack the asker, that's rude.
kaashif 4 hours ago [-]
Can you give an example?
no-name-here 5 hours ago [-]
> AWS saw this growth every year for two decades
That does not seem to be true - which two-decade period are you talking about? AWS has only been around for ~20 years, and I just reviewed a 10 year period, and not a single one of those years saw doubling in the whole year, let alone doubling in a few months. Which 20 year period are you referring to, and are you referring to doubling every few months over that 20 year period?
trymas 10 hours ago [-]
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
mikert89 9 hours ago [-]
cloud providers and hyper growth tech deal with these growth rates all the time
t-sauer 10 hours ago [-]
Did you read the article? It is growing exponential.
mikert89 9 hours ago [-]
this is common at AWS/cloud providers
sandeepkd 9 hours ago [-]
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
muglug 9 hours ago [-]
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.
sandeepkd 8 hours ago [-]
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
Anon1096 8 hours ago [-]
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.
sandeepkd 8 hours ago [-]
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.
kloop 8 hours ago [-]
Sure, but the new patterns are several years old at this point.
Not adapting is a choice
tecleandor 7 hours ago [-]
If you grow 2x a month, you'll run out of resources very soon. Like the whole Solar System.
slashdave 7 hours ago [-]
Hey, um. Little bit of math. Exponential growth.
madrox 7 hours ago [-]
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.
If pushes are the main problem, they could rate limit too.
bug-test-123 3 hours ago [-]
Yes, but there are sharks in the water. Can GitHub afford to lose less money than them, at a slower rate?
underdeserver 2 hours ago [-]
Yes, they can, because I don't think other forges are actually making money.
GitHub is the de facto standard.
iot_devs 54 minutes ago [-]
> 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.
I operated services at similar scale, and generally we use to put a bit of slack so that you would get an alarm when capacity goes up to 80%+ (or whatever number makes sense)
This allows to check, in the morning, after coffee, why the load balancer fleet didn't scale up automatically.
I am sure there is a good answer to why this is impractical, but it would be nice to know
aesthetics1 9 hours ago [-]
> 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.
ethagnawl 5 hours ago [-]
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.
peab 4 hours ago [-]
This comment comes up over and over again and it's incredibly ignorant.
To give just a single example, ai code dev has enabled people to make tools for themselves that they didn't have before.
I've made a language learning app for myself. Its working better than Duolingo so far, for me. Its not really public
throwawayqqq11 36 minutes ago [-]
Speaking of ignorance, how does your success story relate to the societal issues GP brought up?
georgel 4 hours ago [-]
On the topic of translation/ language learning, I still find Google Translate better for when I need to type emails in Russian (my older family who only speak it) as far as grammar is concerned than what LLMs spit out.
dca88 4 hours ago [-]
Why is it incredibly ignorant? Where is he wrong? We have definitely lost the plot.
zombot 2 hours ago [-]
Having an app means exactly nothing. How good your language skills will be after N years of learning is the actual measure of whether it's worth anything.
27183 3 hours ago [-]
> ai code dev has enabled people to make tools for themselves that they didn't have before.
...that sounds pretty worthless tbh. The promise of AI wasn't that you can bang out your own little half baked duolingo clone. It was that every engineer was supposed to become hundreds or thousands of percent more productive. The assumption being that things generally would therefore get noticeably better.
We're seeing hundreds of percent more commits. We're not seeing that translate to any real world improvement of anything. That's the problem.
Call me "ignorant" if you want, but back it up by showing what all this "AI productivity" has actually accomplished in real economic terms. Not vaporware.
globular-toast 2 hours ago [-]
Are you going to be writing your own exam too?
kulahan 7 hours ago [-]
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.
dapperdrake 9 hours ago [-]
Cry in story points. Like a real scrum master level 9000.
ryanchants 4 hours ago [-]
Is it a "productivity panic"? I'm personally pushing a lot more commits because I'm spending more time playing around with ideas on side projects.
Is this all wasted if commits drop in a few months because folks are just pushing a lot now to figure out what works and what doesn't and we eventually settle into something between where we are now and where we were a year ago?
cube00 9 hours ago [-]
> 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.
jdm2212 9 hours ago [-]
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.
jordanb 9 hours ago [-]
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
jdm2212 9 hours ago [-]
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.
dannyw 8 hours ago [-]
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.
jdm2212 8 hours ago [-]
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.
unscaled 5 hours ago [-]
> To handle this correctly you need your RPC framework to accurately communicate retryable vs non-retryable failures to clients.
Even this is not enough, since you cannot always reliably know whether service B is dead or suffers an intermittent issue that can be safely retried just from looking at a single failure.
The classic solution, in the monolith/few-services world would be a circuit breaker. High failure rates on any service trigger a circuit breaker in the services calling it, and they'll wait for a cooldown period before trying again.
When you move to a massive microservice architecture with hundreds or thousands of microservices, setting up circuit breakers manually becomes very hard to track and do reliably. Service meshes like Istio make this slightly easier, but they still don't let you verify that all possible paths have circuit breakers and that retries are not excessive etc.
andrekandre 6 hours ago [-]
> To handle this correctly you need your RPC framework to accurately communicate retryable vs non-retryable failures to clients.
basically enumerate your errors, and depending on the type, retry or just return/forward that same "dont retry this" error?
jdm2212 5 hours ago [-]
Pretty much, but ideally it should be transparent to your app developers. App developer writes `rpc.doThing(...)` on one side, and an implementation on the other, and the infrastructure -- the RPC framework or the service mesh or whatever -- transparently handles when/whether to retry and where to route retries.
grim_io 9 hours ago [-]
Why? You can retry, but there is nothing wrong with increasingly waiting slightly longer if we fail many times.
Dylan16807 5 hours ago [-]
"exponential" and "slightly longer" are very different backoff patterns.
jdm2212 8 hours ago [-]
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.
ctvo 8 hours ago [-]
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 whole point of exponential backoff is that the first retry can be quick.
jdm2212 8 hours ago [-]
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).
throwawayqqq11 27 minutes ago [-]
Thats why you only back off at the edges, (not internally, where you can spin up on demand) and why you should add jitter to the timing.
“Circuit breakers, where calls to a downstream service are stopped entirely when an error threshold is exceeded, are widely promoted to solve this problem. Unfortunately, circuit breakers introduce modal behavior into systems that can be difficult to test, and can introduce significant additional time to recovery. We have found that we can mitigate this risk by limiting retries locally using a token bucket. This allows all calls to retry as long as there are tokens, and then retry at a fixed rate when the tokens are exhausted.”
unscaled 4 hours ago [-]
In highly distributed microservice architecture, there's almost never a single upstream. In some cases you may have a couple of customer-facing entry-points (a global API gateway, and a couple of BFFs), but these are not the only paths that need to be protected.
There are client-side retries (which have broken GitHub in this case) and server-side initiated API calls between microservices that don't pass through any of your ingresses (e.g. triggered by an ETL pipeline, or a scheduled job).
With a complex architecture you can't just slap a circuit breaker on a couple of ingresses and call it a day. Don't get me wrong, putting them there does go a long way, but you won't be covering all your bases.
llama052 4 hours ago [-]
I completely agree, I currently manage a fleet of microservices that handles a few trillion requests a month. It’s about defense in layers to these sorts of things. All the way through the stack if possible starting at the edge.
At least it should be required for critical level services in production.
jdm2212 8 hours ago [-]
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).
llama052 4 hours ago [-]
Ideally you have levers further up from your local load balancers as well. Even at the edge. Granted you never want those to trigger but it’s better than fighting a storm while you fix things.
otterley 2 hours ago [-]
I wondered that myself. Curious as to why they couldn’t shed load at the edge to help protect goodput.
Maxion 58 minutes ago [-]
Isn't that what they did though? Start returning more-or-less hardcoded 403s for the Copilot endpoint that was causing the issues?
2 hours ago [-]
vlovich123 8 hours ago [-]
> 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
dapperdrake 9 hours ago [-]
CAP theorem. Pick one of those.
MrWiffles 5 hours ago [-]
We used to be able to afford two! Acronym letters cost as much as houses nowadays!
> 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.
hirvi74 5 hours ago [-]
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.
nnx 44 minutes ago [-]
> Some days, I would seriously rather work at Wendy's.
Narrator: He would not.
sqquima 9 hours ago [-]
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.
skissane 8 hours ago [-]
> 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
tverbeure 6 hours ago [-]
They added 3 million CPUs. You reduce the complexity of their systems to a unit test…
_kidlike 2 hours ago [-]
So, in all of your software, you have introduced randomness in your retries so that the billions of your clients avoid retry synchronization dances?
Lammy 7 hours ago [-]
> a wider trend to avoid showing the user any error at all costs
> 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".
giancarlostoro 8 hours ago [-]
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.
chasd00 6 hours ago [-]
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).
XorNot 9 hours ago [-]
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).
ACCount37 8 hours ago [-]
"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.
dang 4 hours ago [-]
"Please don't sneer, including at the rest of the community." It's reliably a marker of bad comments and worse threads, and you can make your substantive points without it.
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.
lbrandy 8 hours ago [-]
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.
Breakthrough 7 hours ago [-]
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?
lbrandy 5 hours ago [-]
Some anecdotes
1. People add retries w/o backoff. Now we have a retry storm.
2. People don't add jitter so we get huge waves of highly correlated retries that cause self-perpetuating overload cycles and failure.
3. People add retries (even w/ backoff) at more than one layer (e.g. one in process, one in envoy), so now we have a deeply confusing multi-level of retries with super weird n^2 patterns.
4. People find ways to fetch from multiple data sources to make a composite object but don't cache/reuse data they fetched, so one data source being down causes DOS on _other_ data sources because of retries.
5. People add failover mechanisms where all failures happily pick the same failover target because, ya know, it has the most free capacity.
6. People underestimate connection setup cost so "failover" causes huge increase in overall load due to connection setup (often tls setup) causing huge influx of "new" cpu work in a loaded system. CPU spike causes unhealthy destinations, causing more failovers, causing metastable failure.
7. People realize purely local decisions aren't optimal so add a layer of global health metrics (e.g. global retry budgets) but these systems add a time delay to the metric (ie its the view of the world 5ms ago). This delay makes their naive control algorithm go into oscillations or divergence spraying stuff everywhere.
All of these things have a similar pattern that when things are almost all good, they will make the system more robust. You'll get an extra 9 of reliability on good days. But they make everything far worse when things are bad.
aprdm 6 hours ago [-]
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
hinkley 4 hours ago [-]
For resolution of a problem you can’t prevent categorically, you have to spend a good bit of time pretending to be the computer before you can trust the computer to do it. A run book is a draft of a requirements doc for a program to do the same thing. And you can’t afford to test that program in production without loads of simulations first. And that’s running the process manually and checking aggressively for any signs of problems.
Some coworkers snaked the autoscaling work out from under me, and then ignored the advice I offered on low water marks and weeks of testing and rehearsals. All I can figure about their irrational exhuberence is something to do with claiming something for annual reviews? All I do know is we didn’t make it 40 hours from when they flipped it on until we had our worst outage in two years. Classic FAFO.
They were hoping to eventually get to a low water mark of just over 30% of our static cluster size, and they decided to use that for their initial go instead of my estimate of 40% being the low, and a recommendation that they start with 50-60% for the initial weeks and then ramp it down. When I refused to let it go in the status meeting, the team decided we should vote on it. Two guesses how that went.
A bug in the deployment logic the Ops team had for doing things like upgrading VMs caused the next update during daylight hours to spin up the new instances at the minimum cluster size, instead of the current cluster size. It was done outside peek hours but that still had us cut over with just under half of the hardware we needed at that moment. Because we were in such a fucking hurry to be something like third in line to use the new autoscaling support, nobody else had run into this problem yet (or system did a pretty good job of buffering everyone else).
A couple weeks later they’d looked at the stats and decided that we were spending less than a half hour a day running at the low water mark, and the additional shutdowns were causing churn that made it harder for us to detect problems like memory leaks. Surprise, surprise, they increased the min cluster size to exactly what I’d told them two weeks before.
Since “listen to me” isn’t a lesson that transfers to other teams, I will instead say, don’t transfer initiatives to a new team when there is less than 10% of the project left. The lack of friction you encounter may result in a lack of respect for the danger, and attention to potential problems. And if you must transfer, if your ideas about rollout timeline end up being less conservative than theirs, be patient and do it the slow way. They probably have encountered problems you haven’t seen yet.
eudamoniac 5 hours ago [-]
Could you elaborate on why that would cause more downtime?
unscaled 5 hours ago [-]
I think the "happy path" might be a slightly wrong classification in GP, since the post is in reply to a retry-storm issue and explicitly talks about retry storms and thundering herds.
I've seen many cases where engineers optimize the sad path, but pessimize the wretched path. Or in less flowery language, they cut the occurrence rate of common non-critical failures, but by doing that they introduce code that can make rare failures much worse.
The cases I've seen generally boil down to naive retry logic or poorly tested and poorly maintained fallback paths (such as killswitches that break their environment[1], graceful degradation turned graceless, dormant feature flags that get reactivated).
The case you see with a retry storm here is the most classic one and the one that annoys me the most. I've seen engineers adding aggressive retries even into places where the impact is minor (you could show an error and let the user manually retry instead). Retries that improve user experience can be great if done correctly, but I've never seen the authors of such pull request addressing the risk and mitigation techniques for retry storm or retry amplification.
I've seen cases which had:
1. Retries on the client side (browser or mobile app).
2. Retries on the BFF.
3. Retries on Microservice A used by the BFF.
4. Retries on Microservice B used by Microservice A.
5. Retries on Critical Service C used by Microservice B.
Most of these retries had very short timeouts (e.g. 100ms), in order to keep latency SLOs during normal operations (not a good idea on retries). Every time QA saw a layer without retries, that would be a bug, and adding retries is easy, so we'd get a new retry without much thought. But the first time Critical Service C became overloaded, Microservice B started timing out a couple of times and retrying. This was too much too much for Microservice A that had a short timeout that couldn't hold the 3 retries done by Microservice B, so it making doing its own retries, all of them dropped in the middle of the way. Eventually you'll get a full-blown retry storm where every request from the client side got amplified with 3^5 retries, easily bringing down Critical Service C.
We'd usually introduce a circuit breaker for the particular path that caused the issue, but a variation of this kept happening several times because designing safe retries across a vast collection of microservices takes a lot of effort, and it's always easier to just add a quick-and-dirty retry at any point where you think you might need one and call it a day.
A proper solution (which I've never seen implemented) would be an mandating a corporate-wide inventory of retry-paths, and monitoring it for any path that is at risk of triggering a retry storm, or adding mandatory headers that cross microservices and track the amount of retries done up the chain and the time spent in total waiting for previous retries. You could have a budget for both and automatically stop performing more retries. Both solution require extra effort and a large degree of coordination.
> I've seen many cases where engineers optimize the sad path, but pessimize the wretched path.
As said GP, yes this is exactly what I meant and "happy-path" was an unclear choice of words. They optimize for the unhappy path on the good days, and make the bad days much worse.
Dylan16807 5 hours ago [-]
> 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.
swat535 5 hours ago [-]
More like: those tests are useless because the fundamental system design is garbage thanks to the incompetence of corporations.
dannyw 8 hours ago [-]
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.
noir_lord 8 hours ago [-]
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.
mey 7 hours ago [-]
What do you use now and what is your primary use case?
john01dav 7 hours ago [-]
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).
katbyte 5 hours ago [-]
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
hirvi74 5 hours ago [-]
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.
psunavy03 5 hours ago [-]
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.
bfrog 5 hours ago [-]
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
TomBombadildoze 8 hours ago [-]
Lots of keyboard warriors here, very few of them solving real problems at scale.
sien 7 hours ago [-]
Ironically wouldn't someone who solves real problems at scale actually be a 'keyboard warrior'?
busterarm 7 hours ago [-]
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.
lll-o-lll 7 hours ago [-]
Clearly we have the same employer. Get off hacker news and get back to work!
antonvs 4 hours ago [-]
I had to explain to a “senior” engineer the other day (read: a few years experience) why locating a database client in a different geo region from the server is a bad idea (especially when that client is using an ORM that likes to make lots of little calls to the server.)
I also had to argue for changing a system that was reading about 100k small files from cloud storage to use a single compressed file. There seemed to be no awareness that copying 100k files might be inefficient.
busterarm 3 hours ago [-]
One company I was at sold its product claiming any changes you made were “near instantly published” globally. They tried to demo it as such.
The way the engineers built the update/publish operation was synchronous from their primary data center to a number of globally distributed data centers. Publish didn’t “complete” until a receiver in each data center responded with an ACK after parsing and uploading to a nearby region cloud bucket. Any failure/timeout caused the entire transaction across all data centers to retry. All of traffic was over multiple VPNs, hub and spoke style. They built this system in 2020.
They constantly complained and generated incident reports about p95/p99 latencies to the Asia regions. Latencies that were perfectly reasonable when you considered the multiple global round trips that were being made, the size/volume of objects in the publish, set of operations and speed of light.
They swore that because the client UX to publish the change to the primary data center used JavaScript async that the entire process was async. They denied repeatedly that their “all receivers ack complete to succeed” business logic was synchronous. I shit you not.
hirvi74 5 hours ago [-]
At least they aren't creating new problems at scale either.
19skitsch 5 hours ago [-]
^ this lol, real world systems are so much more complex and involve much more coordination than a personal pet project. It’s so difficult to figure out the source of a bug in a production system like this.
pmarreck 7 hours ago [-]
This is what I think of when people complain about the quality of code from AI agents.
wat10000 8 hours ago [-]
Test coverage varies a lot, but error paths seem almost universally untested.
jambalaya8 7 hours ago [-]
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).
normie3000 6 hours ago [-]
Is GitHub a tech company? Because that's who they're criticising.
antonvs 4 hours ago [-]
At a tech company, engineers mostly work on software that is the company’s product, and as such its functionality, reliability etc. are high company priorities, and the whole company is focused on producing and selling those products.
At a non-tech-company, that’s not the case. Which means you end up with something much closer to the movie “Office Space”, where software is just considered a necessary evil that’s worked on by what’s essentially the software development arm of an IT department, where any opportunity to cut costs or headcount is considered a good idea, where “best practices” take a back seat to “any practice that Bob can make work.”
A lot of companies these days are somewhere between the two: their main product is not software, but the company depends on a website to interact with a large number of customers: banks, insurance companies, web stores, etc. In that case, you tend to get the worst of both worlds, naturally.
cube00 8 hours ago [-]
> 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?
Olreich 8 hours ago [-]
It's less about "can't afford" and more about "don't want to spend".
fg137 7 hours ago [-]
> 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.
bonesss 1 hours ago [-]
In .Net-land we have access to a lot of the underlying MS library code, and reflection/decompilation if needed.
MS has layers, there are A-teams, B-teams, and so-on. Simultaneously they are dropping both world class work and, to your point, a statistically much larger pool of just pretty good code.
A lot of that work is perfunctory and somewhat bloated/weakened by the scale of publishing and their internal tech-political requirements. Components for component I’ve seen in-house replacements for many MS projects from mid-tier devs that are better, smaller, and less brittle over time.
I’d compare it to baking: a home cook or tiny bakery have the advantages of time and focus, perpetual consistency at scale is a whole different baking challenge, one that doesn’t necessarily yield better individual loaves. It doesn’t mean WonderBread is bad at bread, just that they’re optimized for something other than maximal loaf quality.
999900000999 6 hours ago [-]
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.
hirvi74 5 hours ago [-]
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.
beyonddream 8 hours ago [-]
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.
jldugger 8 hours ago [-]
I mean, there are many unserious engineers in corporate America.
hizyyo 9 hours ago [-]
[flagged]
arn3n 10 hours ago [-]
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.
bentt 5 hours ago [-]
This is like letting someone stay in your house for free while charging them to burn it down.
asdfsa32 3 hours ago [-]
If you can sell them fuel, it might be a lucrative business.
zombot 2 hours ago [-]
The long view is that MS will sell those developers the tools that slow down or put band-aids on the damage they inflict on their own codebases by using AI.
OJFord 10 hours ago [-]
> 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?
madeofpalk 10 hours ago [-]
I presume there’s a lot of companies out there paying GitHub very large sums to host all their private repos.
OJFord 10 hours ago [-]
No doubt. ...You can have non-zero revenue and still be loss-making though.
conductr 9 hours ago [-]
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.
otterley 2 hours ago [-]
> what suggests GitHub has a huge operating cost?
They just added 3 million CPU cores to the fleet. That’s a lot of cheddar.
boldlybold 9 hours ago [-]
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.
9 hours ago [-]
scottchiefbaker 8 hours ago [-]
[dead]
stillpointlab 6 hours ago [-]
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.
10 hours ago [-]
RunSet 9 hours ago [-]
Microsoft has a financial incentive to push LLMs and also an existential reason since LLM-generated code is incompatible with the GPL.
skeeter2020 9 hours ago [-]
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.
fastball 9 hours ago [-]
What Microsoft models?
functionmouse 7 hours ago [-]
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.
jdm2212 11 hours ago [-]
> 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 :(
k33P1Tr3aL 11 hours ago [-]
the 'ol thundering herd problem...
pixl97 11 hours ago [-]
Exponential backoff is your friend... too few people use it.
SAI_Peregrinus 10 hours ago [-]
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.
to11mtm 9 hours ago [-]
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...)
llama052 8 hours ago [-]
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.
antonvs 4 hours ago [-]
In general, helping prevent retry storms is one of the functions of a service mesh. E.g. Istio lets you configure exponential backoff with jitter, linkerd provides a retry budget and loadshedding based on backpressure.
“Adding complexity to the reverse proxy” is kind of the central feature of service meshes, but the point is you pick one that’s battle tested and solves more problems than it creates.
r3trohack3r 10 hours ago [-]
Don’t forget jitter!
Aachen 10 hours ago [-]
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?
nater5000 9 hours ago [-]
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.
Maxion 49 minutes ago [-]
Even if you're operating at a scale where thundering herd won't crash your service, introducing exponential backoff + jitter to your retries also helps when you're just viewing the logs. Massively reduces log spam when you make changes.
dadadad100 8 hours ago [-]
It’s a fundamental property of Ethernet[1]. Does that count?
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.
allthetime 7 hours ago [-]
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.
7 hours ago [-]
r3trohack3r 10 hours ago [-]
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.
pixl97 8 hours ago [-]
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.
christophilus 10 hours ago [-]
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.
kbbgl87 10 hours ago [-]
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?
jhealy 9 hours ago [-]
Reminds me of this blog post I read yesterday, about Buildkite introducing jitter in their CI agent to reduce synchronisation
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.
Maxion 48 minutes ago [-]
Cap the number of retries before the user has to manually try again. That's fine.
Quarrelsome 9 hours ago [-]
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
taylor-s 8 hours ago [-]
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.
stingraycharles 8 hours ago [-]
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.
sqquima 8 hours ago [-]
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.
stingraycharles 6 hours ago [-]
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.
MeetingsBrowser 8 hours ago [-]
I think the “thundering herd” problem is pretty extensively documented
__turbobrew__ 5 hours ago [-]
Don't forget jitter as well. Otherwise your clients will just coordinate their retries.
Quarrelsome 8 hours ago [-]
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?
stingraycharles 8 hours ago [-]
Google “thundering herd” and you’ll understand why uncontrolled retries can be / are bad.
MeetingsBrowser 8 hours ago [-]
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
GeorgeDewar 9 hours ago [-]
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.
wat10000 8 hours ago [-]
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.
frollogaston 6 hours ago [-]
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.
wat10000 4 hours ago [-]
I’m sure some retries are helpful there too (TCP is doing them, at the very least) but yeah, different approaches for different situations. Maybe you retry but you don’t spend many seconds hoping for it to work.
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.
frollogaston 6 hours ago [-]
Oh and this is already assuming the blind retries are randomized exponential backoff. Thought it went without saying but maybe not.
madeofpalk 9 hours ago [-]
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.
dapperdrake 9 hours ago [-]
It seems like retries are sometimes best left to the human being in front of the screen. Works well enough.
_fzslm 1 hours ago [-]
I appreciate the unprecedented load GitHub is currently experiencing, but it's not just the (admittedly extreme) load of commits/pushes that is to blame.
Their Copilot cloud agent offering is suffering with a case of some of the worst corporate ADHD I've seen. We built a cloud agentic development pipeline on it, and it seems like almost every other week they silently change something with zero public announcement that creates real disruption for our team.
Note: that's not bugs in the Copilot platform like the article discusses. That's real, breaking changes to the platform that clearly aren't being tested/reviewed before being pushed to prod, with zero public announcement or documentation.
Support is useless – we're paying customers in the 4-5 figures and our tickets go unanswered.
I love(d) GitHub, but I do think they've lost enough public trust at this point that their time is ticking. With talk of new VCSes designed specifically for agents, I do believe it is just a matter of time. Which pains me somewhat to say.
hnburnsy 5 hours ago [-]
>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.
StilesCrisis 9 hours ago [-]
"... 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.
nickelpro 6 hours ago [-]
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.
tcmart14 4 hours ago [-]
I may have come out with a different interpretation than you did of GP's comment. I see how you got to yours. But the way I read them saying they should slow down was, maybe slow down on new features. Which would mean they could shift resources from new features to infra.
altcognito 8 hours ago [-]
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.
Maxion 44 minutes ago [-]
The point is, GitHub is not free for me (we pay) yet we were also down?
IMO definiely time to segregate the free and the paid service. Otherwise those of us who need the service to stay up will have to look for alternatives.
The post mortem conclusion should've been to put usage limits on the free tier so paid users aren't killed by them.
tcmart14 4 hours ago [-]
My only push back would be on the FREE part. I coulda bought that 5 years ago. Now I look at GitHub and go, "if the product is free, it's because Im the product" with all their co-pilot stuff.
altcognito 3 hours ago [-]
Another fair take. I mean, hell, a lot of companies are bought literally just for their user lists (to sell new products to). I can't think of a nicer user list than a list of potential developers.
tcmart14 3 hours ago [-]
My guess is, user list would be the least. Microsoft has this thing about getting you all warm and snug because they have a solution for everything. Need an IDE? VS Code and VS proper. Got your hosting needs (azure). Literally everything. You wanna build applications around AI. We got you too, along with the VCS to keep your app in and pipelines. Hey, go ahead and send us your data so your AI application is better because you're really just calling our models. Right, and this goes even further. Data is incredibly valuable. And here we are, now paying companies to vacuum up all our data. Every last bit. And I am just seeing GitHub as another way to get people in the door to do just that.
Probably the biggest thing that has me dumbfounded about everything in the AI space and the tooling in GitHub and stuff with co-pilot. They've figured out a way to make us pay them to steal all our valuable data. And to package it up all nice for them with a bow on it and not question it.
steve-atx-7600 8 hours ago [-]
“ Name another service that does what they do for FREE (and no ads) at this scale” and is reliable is the question
altcognito 8 hours ago [-]
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.
mark89h 3 minutes ago [-]
nice
teiferer 52 minutes ago [-]
> Both incidents were capacity failures at their core. We failed to scale critical components before demand exceeded their capacity.
I'm missing in these descriptions the most obvious approach: Resilience. Shedding load so that you can keep services up even though capacity is too low. If you flip over as soon as load exceeds what you can handle then this problem will never go away, unless you always have insane overprovisioning of resources which is uneconomical. There will always be spikes. You need to plan to handle them, no matter how high.
> we have focused on three priorities: adding capacity, improving efficiency, and removing architectural bottlenecks.
Sorry, but again, that is not good enough. They should ask themselves why they are expecting that trying the same medicine as last time will prevent next time. It won't.
With that mindset I'm not surprised this happened and it will surely happen again.
Edit: In more concrete terms. If you 2x your capacity and in a week you face a burst 2x of what happened last time, you are back in the same seat. If you improve efficiency by 2x, same thing. And after a bottleneck is before a bottleneck. There will always be a bottleneck. The key is to be able to handle a bottleneck. Removing one just pushes the issue to the next one.
Your architecture must be such that your whole system should be able to run on a raspberry pi. Most client requests would be dropped, but those that make it through will be served. If your architecture serves 0% because it crashes when load is 10% over capacity, then capacity increases or efficiency increases or bottleneck removal are not going to prevent the next outage.
iSloth 11 hours ago [-]
Has to be one of the most vague outage summaries of the year
Yeah... it has the vagueness and awkward staccato of heavily edited Claudish.
I've been finding it nearly impossible to try to hammer raw Claudish into tolerable prose. I usually have to re-write most of the text by hand if I want it slop-free.
P.S. Hi Claude! I know you might be reading this :) Don't take it personally. Let your trainers know that you need some help with this.
bearjaws 5 hours ago [-]
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."
smt88 5 hours ago [-]
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.
alex7o 2 hours ago [-]
Cant they just put ai agents at optimizing their slow internal paths.
burstlimit 4 hours ago [-]
After touting 1 billion commits over 2025 at universe last year… they are now handling 3 billion per month jeez. I’ll give them a little more grace after all…
steve1977 2 hours ago [-]
Maybe Github (and especially things like Actions) just need to become more expensive?
ethin 8 hours ago [-]
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.
verzali 9 hours ago [-]
The trend doesn't seem sustainable.
silver92bullet 4 hours ago [-]
This article seems to say that there is "no excuse" for these issues but look at all these things we changed and are changing. It doesn't really feel transparent and it feels like they aren't really taking true ownership on what has happened.
smgpie 43 minutes ago [-]
I have setup a gitea instance on my gitea server which I think is good for me and GitHub both. For one, I dont have to worry about GitHub service outages, and GitHub gets to be free from my toy (and mostly AI slop) projects that no one else will ever read/use/participate in :-)
rrvsh 7 hours ago [-]
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
NameError 6 hours ago [-]
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.
dpweb 11 hours ago [-]
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.
fulafel 1 hours ago [-]
Microsoft are doing many things to help the AI coding surge, I'm not sure if this'd be a cost effective thing towards it.
doginasuit 9 hours ago [-]
You are always paying one way or another, I prefer to pay in dollars and not frustration, attention, or privacy.
autoexec 3 hours ago [-]
Not an option. Companies are happy to sell you products at premium prices, take your money, and then still collect, mine, insecurely store, and sell all your private data.
Shish2k 11 hours ago [-]
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 :(
zelphirkalt 9 hours ago [-]
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.
blitzar 8 hours ago [-]
> service which treats them with respect
Which mythical tech company - free or paid - does this?
chrisjj 11 hours ago [-]
Surely that's the point. Shed users.
dcrazy 11 hours ago [-]
Pay per issue and commit. Buy 1,000 commit credits at a time.
Might force people to review their slop before pushing it.
verdverm 10 hours ago [-]
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
dcrazy 8 hours ago [-]
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.
fukaiall 7 hours ago [-]
Would it be okay to suspect the recent upsurge in AI agent usage as a possible main cause of this issue?
afgrant 3 hours ago [-]
“Required several coordinated actions” is the key moment for reflection.
pooploop64 8 hours ago [-]
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?
kvemkon 11 hours ago [-]
I fear to ask, how archive.org keeps up to catch all those events for archiving...
lonertecher 7 hours ago [-]
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.
yipinwong 11 hours ago [-]
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
jdm2212 11 hours ago [-]
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".
dhruvrrp 10 hours ago [-]
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.
10 hours ago [-]
jdthedisciple 47 minutes ago [-]
i'm not surprised, there are probably millions of 2hr long pipelines (actions) running for like 1-line code changes
today's enterprise devops practices are just a bit brainless
not to mention all the AI commits ofc
Yhippa 6 hours ago [-]
Centralized decentralized code repos. It feels like an oxymoron.
throwaway96230 6 hours ago [-]
5X as much code in <2 years. What is all that software?
pipe01 6 hours ago [-]
AI slop
rarisma 8 hours ago [-]
Github you can only post you are doing stuff about outages if its actually effective.
The vibes are off.
luciana1u 7 hours ago [-]
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.
47635274172635 7 hours ago [-]
What would happen if github was down for like a week?
hbcdbff 1 hours ago [-]
1.5 billion commits of worthless slop
Preston67 4 hours ago [-]
That is amazing
rcleveng 11 hours ago [-]
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.
film42 9 hours ago [-]
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.
rcleveng 11 hours ago [-]
[dead]
sergiotapia 7 hours ago [-]
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?
microscoper 7 hours ago [-]
Yeah you could probably have a very high free limit that works for 99% of people
11 hours ago [-]
CodeCompost 10 hours ago [-]
Central US data center failed to scale with it
I'm in Europe and I experienced token failures as well.
greatgib 6 hours ago [-]
> 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.
ivraatiems 12 hours ago [-]
"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.
dcrazy 11 hours ago [-]
> 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.
"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.
dcrazy 11 hours ago [-]
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.
ivraatiems 11 hours ago [-]
[flagged]
dcrazy 11 hours ago [-]
Baseless accusation made from a position of zero information.
ivraatiems 11 hours ago [-]
Opinion based on stated facts.
Please share the information you have which contradicts the conclusions I have drawn from Github's statement.
I don’t owe you anything, much less a separately sourced counterargument. You openly admit that your opinion is not based not on GitHub’s proffered statements but on your self-admitted assumption that GitHub is actively lying in an attempt to cover up an Azure-related root cause.
maccard 9 hours ago [-]
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.
rcleveng 11 hours ago [-]
There's always a cliff, this part is fine.
You sometimes know the cliff but often do not.
cyberax 11 hours ago [-]
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.
Kinrany 11 hours ago [-]
I believe their point is that "system is at capacity" is something they ought to start fixing before the capacity is exceeded
dcrazy 11 hours ago [-]
But then people like OP will claim that the capacity concerns are a lie manufactured to support an unjustified move to Azure.
cyberax 11 hours ago [-]
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.
>"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.
kjellsbells 11 hours ago [-]
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.
bpavuk 11 hours ago [-]
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.
DANmode 10 hours ago [-]
What if it was $2?
bpavuk 9 hours ago [-]
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
fragmede 8 hours ago [-]
Oracle has a free tier that you can self host a git server on, if that's what you're looking for.
joezydeco 9 hours ago [-]
The Azure horror stories are on this blog post and HN discussion.
> 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?
ivraatiems 11 hours ago [-]
They had $1b revenue in 2023 and now probably more than $2b in revenue... do you have cost figures showing what their expenses are?
bluedino 11 hours ago [-]
> 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.
cyberax 11 hours ago [-]
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.
anvuong 10 hours ago [-]
$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.
cyberax 9 hours ago [-]
Yup. Still, it's less than their annual income by several times.
bluedino 11 hours ago [-]
Does that $10k server not need RAM?
mh- 10 hours ago [-]
If parent commenter is off by an order of magnitude in their costs, their point still stands.
Goronmon 9 hours ago [-]
$1.2 billion of costs on revenue of $1-$2b certainly seems like a big concern.
mh- 9 hours ago [-]
They do not throw away the servers every year..
kiwijamo 5 hours ago [-]
But at this rate of growth, sounds like they'll need to buy around that amount every year just to keep up with current (not even taking into account future) growth.
awesome_dude 11 hours ago [-]
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.
mort96 11 hours ago [-]
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.
unrented7977 11 hours ago [-]
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.
ivraatiems 11 hours ago [-]
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.
mort96 11 hours ago [-]
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.
Shish2k 11 hours ago [-]
"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
rcleveng 11 hours ago [-]
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
otterley 2 hours ago [-]
GitLab has its own problems. It might be somewhat more available than GitHub lately, but it too is not immune to incidents, particularly involving workflow dispatch and managed runner availability.
Plus the UX isn’t nearly as good. Sometimes it feels downright clunky in comparison.
mh- 10 hours ago [-]
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.
shimman 10 hours ago [-]
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.
jryan49 7 hours ago [-]
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?
msephton 4 hours ago [-]
I can't speak for all of it, obviously, I don't have time to try much of it, but I see tons of amazing new software in my various feeds pretty much daily.
aryamccarthy 6 minutes ago [-]
I'm a bit weary of seeing comments like this, but I want to believe you, so help me learn? What are some examples of the amazing software you've seen recently?
gigatexal 8 hours ago [-]
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?
sleepybrett 4 hours ago [-]
github controls the productivity of a large number of very large tech companies. When there is an outage like this they are basically shutting down a significant number of factories for hours at a time. This would be as if during the hayday of detroit they just turned off the power grid at a time randomly at least once a week for hours. It's unacceptable. The amount of productivity lost is staggering.
We should be building tools that help us all move off of github as soon as possible. The amount of action code that will need to be rewritten is daunting.
0xbadcafebee 8 hours ago [-]
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.
kypro 9 hours ago [-]
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.
globular-toast 2 hours ago [-]
This seems really bad, to be honest. I think we may be fucked. There's just no way all these lines of code are doing anything useful. We're now just burning stuff in desperation and confusion.
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.
Absolutely do not recommend using GitLab.
0xblinq 11 hours ago [-]
"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.
mananaysiempre 8 hours ago [-]
“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.
You're in luck, GP comment described it for you.
skydhash 9 hours ago [-]
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,…)
denzen 11 hours ago [-]
Have you looked into Forgejo?
verdverm 10 hours ago [-]
I'm particularly fond of the concepts within git-appraise, gits back to the federated foundations
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.
rvz 11 hours ago [-]
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.
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.
john_strinlai 9 hours ago [-]
i am confident that if "sorry" appeared, someone would make a comment about "hollow apologies" or similar.
bibimsz 10 hours ago [-]
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.
CrimsonCape 8 hours ago [-]
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.
7 hours ago [-]
itemize123 6 hours ago [-]
im sorry u feel this way
sajithdilshan 11 hours ago [-]
Bye Felicia
vladsiu 3 hours ago [-]
[dead]
djha-skin 11 hours ago [-]
[dead]
throwaway613746 10 hours ago [-]
[dead]
codegeek 12 hours ago [-]
[dead]
kburman 3 hours ago [-]
Just add a queue. Now the outage is eventually consistent. /s
mnmnmn 10 hours ago [-]
[dead]
rawland 11 hours ago [-]
[flagged]
sajithdilshan 11 hours ago [-]
[flagged]
thesdev 10 hours ago [-]
> the entitled freeloaders
Now remind me again, who trained a coding-assistant without consent on those "freeloaders" code and sold it for profit?
Vegenoid 9 hours ago [-]
Using a corporation's free offerings isn't freeloading. Microsoft wants people to put their code on GitHub. They want GitHub to be the place where source code is hosted, it is incredibly valuable. Saying "GitHub is sucking and I might leave" is information that Microsoft wants to know if they want to preserve GitHub's dominance.
Of course some people take it too far. Of course there are reasons that the outages are occurring. But Microsoft wants GitHub to be a core, reliable pillar of the software world. Nobody's making them do that, they do it because it's good for them.
jiehong 10 hours ago [-]
It seems that paid users are equally impacted as free users.
It sounds a little bit unfair to me.
dataplumb3r 9 hours ago [-]
True but paid users are also impacted.
We're still staying on Github at work, but have had backup self hosted git repos as a break glass option when Github is completely broken and leveraged this several times now.
Brian_K_White 6 hours ago [-]
Whos fault is the massive load increase, or their inability to navigate it?
Did I iject copilot into every part of github? In fact not only did I not insert it, I have never even used it.
Did I move their infrastructure to Azure?
Did I sell them to MS?
Did I set all the directives and priorities that MS has set on them like telling everyone they must use openai for everything, and then telling them they must stop doing that and user their own ai instead?
The outage is not due to a natural disaster that no one could anticipate and no one had any input on creating the conditions. They keep the free tier because THEY want what THEY get from the free tier. They could easily have a $1 tier and various totally sensible throttle limits on various services and apis that would have avoided all this, but that would not get them the 100% user coverage that they want. So THEY choose to provide free, swiss cheese service.
It's not some unreasobable burden they labor under that anyone else should be understanding and forgiving about.
lysace 10 hours ago [-]
"Most people use GitHub and features for free"
Do you have a source for that factoid? (I suspect the vast majority of Github resource usage is paid. And we are upset.)
Aachen 10 hours ago [-]
That sounds unusual for a free platform (not a limited trial but an actual free tier). Isn't it usually the case that only some small percentage can be convinced to pay?
foolswisdom 10 hours ago [-]
They're arguing that most usage of resources would be by companies, who are presumably paying.
Aachen 7 hours ago [-]
I don't think my employer pays for our use of Github. Edit: but, then, perhaps that's why my view is tainted. Point taken!
ssl-3 10 hours ago [-]
Entitlement? Please. It's not like Github is a charity that operates on kindness and goodwill.
It's a service that is owned and operated by Microsoft Corporation, and we're the product of it.
XorNot 9 hours ago [-]
LOL. If it dies, it dies.
People take the weirdest rhetorical hostages.
jvwww 7 hours ago [-]
Agreed - up-time problems have been going on with Github for a while. They need to sort out their problems.
duped 10 hours ago [-]
I mean, a lot of us have paid GitHub a lot of money for CI on private repos. And when GitHub themselves encourages the insane behavior of vibe coders and agents instead of just charging or rate limiting access of bots, it's hard to give them sympathy.
jollyllama 10 hours ago [-]
Meh, just needs better QoS. Let the free tier shoulder the outages.
bibimsz 10 hours ago [-]
well written
pkilgore 8 hours ago [-]
Ctrl+F "Sorry"
No results.
Cool
annoyingnoob 11 hours ago [-]
Github down, no hard drives available, no memory available, thanks AI!
Seems like we are headed for Tech Gridlock.
jdm2212 11 hours ago [-]
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.
a2ff6eeb0 11 hours ago [-]
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!
yoyohello13 8 hours ago [-]
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.
jdm2212 8 hours ago [-]
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.
kyleweng 7 hours ago [-]
probably worth asking when those prices will come down.
jdm2212 3 hours ago [-]
Automation has been making food steadily cheaper for 300+ years, and continues to do so. Sometimes the price of oil goes up so much that fuel and fertilizer price increases negate the wins from automation, but automation is still generating wins and will only accelerate as robots get smarter.
yipinwong 11 hours ago [-]
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 $
jdm2212 11 hours ago [-]
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.
yipinwong 10 hours ago [-]
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.
jdm2212 10 hours ago [-]
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.
yipinwong 2 hours ago [-]
YOu are making an assumption on which LB is down, and so am I.
Where is LB placed? Is that hte LB in front of API GW? or behind GW? GW can have rate limiter or cloudflare FW can handle the rate limiting.
The doc does not show which part of LB is down so it's all guessing at this point so i won't go forward with this.
2 hours ago [-]
danieltk76 9 hours ago [-]
i wanna vibecode a replacement for git and call it jit
monlockandkey 11 hours ago [-]
They should rewrite their Ruby code to a performant language.
delduca 9 hours ago [-]
No sorry we messed up your work?
addaon 10 hours ago [-]
> What we have done and what comes next
"You've seen what we've done. The August 21st outage comes next. See you then!"
jjordan 8 hours ago [-]
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.
subarctic 8 hours ago [-]
Maybe he's too busy with leading the engineering side of the company to write code these days?
Balooga 8 hours ago [-]
If even the CEO is vibe coding[1], then the CTO has zero excuse.
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?
googletron 8 hours ago [-]
yeah grinding on side projects, while everything is in flames.
this is fine.
cactusplant7374 7 hours ago [-]
Probably managing and mentoring. I has a boss that wanted to code and be CTO. Just horrible.
eudamoniac 5 hours ago [-]
Sarcasm? Someone as important as CTO of GitHub is the last person I'd expect to have "side projects". I'm sure his job is project enough.
kjuulh 11 hours ago [-]
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.
xienze 10 hours ago [-]
> 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.
ryanisnan 10 hours ago [-]
Here's Vladimir Fedorov's GitHub contribution graph, as linked to as the author of this post:
It shows zero contributions in the past year, on this account. This is a huge, huge red flag.
reticulates 10 hours ago [-]
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.
ryanisnan 9 hours ago [-]
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.
7 hours ago [-]
mvdtnz 10 hours ago [-]
Mine would look the same if you didn't have access to the private repositories I contribute to at work.
ryanisnan 10 hours ago [-]
Don't contributions to private repositories simply show as: "N contributions in private repositories"?
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.
spongebobstoes 10 hours ago [-]
you have to opt in to private contributions being visible like that
This is the wrong way to think about this because there's no such thing as infinite capacity. A large distributed system will be simultaneously mostly idle and (in some subcomponents) overloaded. The root cause is not "a component didn't have enough capacity (because of auto scaling failures)", but rather "this complex system collapses (rather than degrade gracefully) when demand exceeds capacity".
When components reach capacity limits, the excess traffic of the lowest priority should be rejected. Rejected traffic should not be retried — in fact, not only should clients not retry these errors, these errors should cause client-side throttling. Traffic isolation should be applied — if the cause of the overload is a single client/customer system, no other system should be affected.
Nearly a decade ago I wrote about some of the techniques we applied at Google to implement these protections: https://sre.google/sre-book/handling-overload/ Most other large internet services have since copied them, afaik.
As it happens I have a hardcopy of this book (along with "Seeking SRE" and the "SRE Workbook") that I am giving away (because of a move). If you want a hardcopy then email me your UK address I will be happy to post them to your for free.
I tried putting them on the street in a little box but surprisingly none of my neighbours grabbed any of my software books. :)
If it's not your job, then just ignore the reports.
If it's actually critical, someone will put money on the table and then it's a business. And then it's about scheduling and resourcing - also should not burn anyone out.
Just because many people have false sense of entitlement as soon as they get a free offering, it does not mean anyone needs to accommodate them.
If you have a highly conscientious personality, this is easier said than done.
Higher resource consumption and the set back in CO2 reduction?
On the other hand recent papers highlight the validity of concern/suspicion:
> This systematic review demonstrates that the environmental footprint of artificial intelligence is a structural and increasingly consequential challenge, shaped by interdependent decisions across algorithms, software pipelines, hardware infrastructures, and deployment contexts. The synthesized evidence shows that energy consumption and carbon emissions associated with AI systems are highly variable, context-dependent, and often underestimated — Beyond Efficiency: A Systematic Review of Energy Consumption and Carbon Footprint Across the AI Lifecycle (published in “Sustainability” an international, peer-reviewed, open-access journal) https://www.mdpi.com/2071-1050/18/3/1359
> water is not unlimited
> you don't want to release a bunch of acid into a river
> I know next to nothing about this
> I know basically nothing
> corn is one of the thirstiest major crops grown in the US
What is this rant supposed to inform? Whats wrong with OP being concerned about the costs of operating a DC?
When someone in a discussion about the benefits of AI goes "did you think about the environment?!", it's always performative.
The real motivation is disliking AI itself or doubt about the government's ability to offset the labor market impact. Discussions that start with feigned concerns being raised are nearly always going to be unproductive.
The construction of data centers needs resources and also creates more the CO2.
The energy for these data centers is often created through fossil fuels which also creates additional CO2
What do you think why Google and MS scrapped their CO2 reduction targets
What I have noticed an increase though is in demands and pressure to deliver.
EDIT: Instead of simply down-voting, you're welcome to name examples that proves me wrong ;)
So, if it doesn't then you learned something about your workplace (and it's not good).
But ofc, slop has increased a lot more as well.
How long do they last until the get replaced by the next feature?
I'm sure I'm not alone. While AI luddites are spreading FUD, real builders are building heads down.
https://github.blog/news-insights/product-news/github-copilo...
I've had opus 5 along with its AI code reviewer agree to do some pretty stupid shit.
An issue reported by a person account but post made by AI. https://github.com/oven-sh/bun/issues/39800
AI (robobun) responds and creates PR. https://github.com/oven-sh/bun/pull/37459
AI (coderabbit, claude, github actions) review the PR, AI (robobun) applies the fixes.
Some AI back and forth.
A human finally merges the PR.
Not gonna lie, it's kind of beautiful.
I am currently using bun, but may have to switch. I can't see how this can possibly turn out well in the long run...
https://github.com/oven-sh/bun/issues/39797
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.
https://github.com/oven-sh/bun/pull/39743 https://github.com/oven-sh/bun/pull/39735
robobun: "The ordering is load-bearing: reclaiming before this block made is_dead_request true and hung a parked textStream read (caught by body.test.ts in CI). The comment pins that constraint."
Ah, well, if something is load-bearing, then I guess that settles it. Need a comment to pin that constraint, in case a read is parked. These are words that normal humans commonly use in these ways.
(Always striking how much Claude obsesses over the minutiae of method contracts and side effects, exhaustively documenting them in comments. It’s much happier figuring out how to reorder some method calls with nonobvious side effects so the code works than it is refactoring them not to do unexpected things!)
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?
I don't know how much my own time is wasted on Claude imagining API response formats that never existed.
Unironically: no.
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.
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.
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...
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.
The richest man in the world is interested in this dataset as well.
Or, is the idea just to drive everyone away from your platform?
I feel it in my fingers. I feel it in my veins.
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.
"Our billion-dollar infrastructure crumbles under a tremendous flood of 50 PRs per second" would just sound embarrassing.
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.
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 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.
It’s also like… the core unit of git.
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.
And yes, I agree there is indexing of commits, but that is a batch insert from a log.
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.
"We have since added more than 3 million CPU cores, 120 petabytes of high-speed storage, and significant network capacity"
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.
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…”
General intelligence may still be a ways off.
...what? Seriously though. What grand insight into the arc of AI development do you have? Where are you getting this from? Cite your sources. Show your analysis.
Charitably, I would ask "are you high?".. If you're suffering acute psychosis from mind altering chemicals then we merely have to wait for the effects to wear off and you'll likely recover. If not, then I'm very sorry. Your road ahead is a rough one.
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.
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?
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.
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.
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.
“We misconfigured a sidecar” is something I would think AI could quite easily find and fix.
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
That does not seem to be true - which two-decade period are you talking about? AWS has only been around for ~20 years, and I just reviewed a 10 year period, and not a single one of those years saw doubling in the whole year, let alone doubling in a few months. Which 20 year period are you referring to, and are you referring to doubling every few months over that 20 year period?
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
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
> "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.
Not adapting is a choice
I've been saying this for a while: https://news.ycombinator.com/item?id=47534499
GitHub is the de facto standard.
I operated services at similar scale, and generally we use to put a bit of slack so that you would get an alarm when capacity goes up to 80%+ (or whatever number makes sense)
This allows to check, in the morning, after coffee, why the load balancer fleet didn't scale up automatically.
I am sure there is a good answer to why this is impractical, but it would be nice to know
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.
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.
To give just a single example, ai code dev has enabled people to make tools for themselves that they didn't have before.
I've made a language learning app for myself. Its working better than Duolingo so far, for me. Its not really public
...that sounds pretty worthless tbh. The promise of AI wasn't that you can bang out your own little half baked duolingo clone. It was that every engineer was supposed to become hundreds or thousands of percent more productive. The assumption being that things generally would therefore get noticeably better.
We're seeing hundreds of percent more commits. We're not seeing that translate to any real world improvement of anything. That's the problem.
Call me "ignorant" if you want, but back it up by showing what all this "AI productivity" has actually accomplished in real economic terms. Not vaporware.
Is this all wasted if commits drop in a few months because folks are just pushing a lot now to figure out what works and what doesn't and we eventually settle into something between where we are now and where we were a year ago?
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.
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.
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.
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.
Even this is not enough, since you cannot always reliably know whether service B is dead or suffers an intermittent issue that can be safely retried just from looking at a single failure.
The classic solution, in the monolith/few-services world would be a circuit breaker. High failure rates on any service trigger a circuit breaker in the services calling it, and they'll wait for a cooldown period before trying again.
When you move to a massive microservice architecture with hundreds or thousands of microservices, setting up circuit breakers manually becomes very hard to track and do reliably. Service meshes like Istio make this slightly easier, but they still don't let you verify that all possible paths have circuit breakers and that retries are not excessive etc.
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
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).
I’m particularly fond of the token-bucket mechanism for pacing recovery.
“Circuit breakers, where calls to a downstream service are stopped entirely when an error threshold is exceeded, are widely promoted to solve this problem. Unfortunately, circuit breakers introduce modal behavior into systems that can be difficult to test, and can introduce significant additional time to recovery. We have found that we can mitigate this risk by limiting retries locally using a token bucket. This allows all calls to retry as long as there are tokens, and then retry at a fixed rate when the tokens are exhausted.”
There are client-side retries (which have broken GitHub in this case) and server-side initiated API calls between microservices that don't pass through any of your ingresses (e.g. triggered by an ETL pipeline, or a scheduled job).
With a complex architecture you can't just slap a circuit breaker on a couple of ingresses and call it a day. Don't get me wrong, putting them there does go a long way, but you won't be covering all your bases.
At least it should be required for critical level services in production.
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
https://web.archive.org/web/20250128235041/https://codahale....
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.
Some days, I would seriously rather work at Wendy's.
Narrator: He would not.
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
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...
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".
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).
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.
https://news.ycombinator.com/newsguidelines.html
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/
1. People add retries w/o backoff. Now we have a retry storm.
2. People don't add jitter so we get huge waves of highly correlated retries that cause self-perpetuating overload cycles and failure.
3. People add retries (even w/ backoff) at more than one layer (e.g. one in process, one in envoy), so now we have a deeply confusing multi-level of retries with super weird n^2 patterns.
4. People find ways to fetch from multiple data sources to make a composite object but don't cache/reuse data they fetched, so one data source being down causes DOS on _other_ data sources because of retries.
5. People add failover mechanisms where all failures happily pick the same failover target because, ya know, it has the most free capacity.
6. People underestimate connection setup cost so "failover" causes huge increase in overall load due to connection setup (often tls setup) causing huge influx of "new" cpu work in a loaded system. CPU spike causes unhealthy destinations, causing more failovers, causing metastable failure.
7. People realize purely local decisions aren't optimal so add a layer of global health metrics (e.g. global retry budgets) but these systems add a time delay to the metric (ie its the view of the world 5ms ago). This delay makes their naive control algorithm go into oscillations or divergence spraying stuff everywhere.
All of these things have a similar pattern that when things are almost all good, they will make the system more robust. You'll get an extra 9 of reliability on good days. But they make everything far worse when things are bad.
Some coworkers snaked the autoscaling work out from under me, and then ignored the advice I offered on low water marks and weeks of testing and rehearsals. All I can figure about their irrational exhuberence is something to do with claiming something for annual reviews? All I do know is we didn’t make it 40 hours from when they flipped it on until we had our worst outage in two years. Classic FAFO.
They were hoping to eventually get to a low water mark of just over 30% of our static cluster size, and they decided to use that for their initial go instead of my estimate of 40% being the low, and a recommendation that they start with 50-60% for the initial weeks and then ramp it down. When I refused to let it go in the status meeting, the team decided we should vote on it. Two guesses how that went.
A bug in the deployment logic the Ops team had for doing things like upgrading VMs caused the next update during daylight hours to spin up the new instances at the minimum cluster size, instead of the current cluster size. It was done outside peek hours but that still had us cut over with just under half of the hardware we needed at that moment. Because we were in such a fucking hurry to be something like third in line to use the new autoscaling support, nobody else had run into this problem yet (or system did a pretty good job of buffering everyone else).
A couple weeks later they’d looked at the stats and decided that we were spending less than a half hour a day running at the low water mark, and the additional shutdowns were causing churn that made it harder for us to detect problems like memory leaks. Surprise, surprise, they increased the min cluster size to exactly what I’d told them two weeks before.
Since “listen to me” isn’t a lesson that transfers to other teams, I will instead say, don’t transfer initiatives to a new team when there is less than 10% of the project left. The lack of friction you encounter may result in a lack of respect for the danger, and attention to potential problems. And if you must transfer, if your ideas about rollout timeline end up being less conservative than theirs, be patient and do it the slow way. They probably have encountered problems you haven’t seen yet.
I've seen many cases where engineers optimize the sad path, but pessimize the wretched path. Or in less flowery language, they cut the occurrence rate of common non-critical failures, but by doing that they introduce code that can make rare failures much worse.
The cases I've seen generally boil down to naive retry logic or poorly tested and poorly maintained fallback paths (such as killswitches that break their environment[1], graceful degradation turned graceless, dormant feature flags that get reactivated).
The case you see with a retry storm here is the most classic one and the one that annoys me the most. I've seen engineers adding aggressive retries even into places where the impact is minor (you could show an error and let the user manually retry instead). Retries that improve user experience can be great if done correctly, but I've never seen the authors of such pull request addressing the risk and mitigation techniques for retry storm or retry amplification.
I've seen cases which had:
1. Retries on the client side (browser or mobile app). 2. Retries on the BFF. 3. Retries on Microservice A used by the BFF. 4. Retries on Microservice B used by Microservice A. 5. Retries on Critical Service C used by Microservice B.
Most of these retries had very short timeouts (e.g. 100ms), in order to keep latency SLOs during normal operations (not a good idea on retries). Every time QA saw a layer without retries, that would be a bug, and adding retries is easy, so we'd get a new retry without much thought. But the first time Critical Service C became overloaded, Microservice B started timing out a couple of times and retrying. This was too much too much for Microservice A that had a short timeout that couldn't hold the 3 retries done by Microservice B, so it making doing its own retries, all of them dropped in the middle of the way. Eventually you'll get a full-blown retry storm where every request from the client side got amplified with 3^5 retries, easily bringing down Critical Service C.
We'd usually introduce a circuit breaker for the particular path that caused the issue, but a variation of this kept happening several times because designing safe retries across a vast collection of microservices takes a lot of effort, and it's always easier to just add a quick-and-dirty retry at any point where you think you might need one and call it a day.
A proper solution (which I've never seen implemented) would be an mandating a corporate-wide inventory of retry-paths, and monitoring it for any path that is at risk of triggering a retry storm, or adding mandatory headers that cross microservices and track the amount of retries done up the chain and the time spent in total waiting for previous retries. You could have a budget for both and automatically stop performing more retries. Both solution require extra effort and a large degree of coordination.
[1] This was the CloudFlare issue mentioned in this thread https://blog.cloudflare.com/5-december-2025-outage/
As said GP, yes this is exactly what I meant and "happy-path" was an unclear choice of words. They optimize for the unhappy path on the good days, and make the bad days much worse.
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.
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 recently tried zed but it ddos’d my nas over an smb share lol
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.
I also had to argue for changing a system that was reading about 100k small files from cloud storage to use a single compressed file. There seemed to be no awareness that copying 100k files might be inefficient.
The way the engineers built the update/publish operation was synchronous from their primary data center to a number of globally distributed data centers. Publish didn’t “complete” until a receiver in each data center responded with an ACK after parsing and uploading to a nearby region cloud bucket. Any failure/timeout caused the entire transaction across all data centers to retry. All of traffic was over multiple VPNs, hub and spoke style. They built this system in 2020.
They constantly complained and generated incident reports about p95/p99 latencies to the Asia regions. Latencies that were perfectly reasonable when you considered the multiple global round trips that were being made, the size/volume of objects in the publish, set of operations and speed of light.
They swore that because the client UX to publish the change to the primary data center used JavaScript async that the entire process was async. They denied repeatedly that their “all receivers ack complete to succeed” business logic was synchronous. I shit you not.
At a non-tech-company, that’s not the case. Which means you end up with something much closer to the movie “Office Space”, where software is just considered a necessary evil that’s worked on by what’s essentially the software development arm of an IT department, where any opportunity to cut costs or headcount is considered a good idea, where “best practices” take a back seat to “any practice that Bob can make work.”
A lot of companies these days are somewhere between the two: their main product is not software, but the company depends on a website to interact with a large number of customers: banks, insurance companies, web stores, etc. In that case, you tend to get the worst of both worlds, naturally.
It's Microsoft, if they can't afford to do comprehensive unit testing, what hope do the rest of us have?
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.
MS has layers, there are A-teams, B-teams, and so-on. Simultaneously they are dropping both world class work and, to your point, a statistically much larger pool of just pretty good code.
A lot of that work is perfunctory and somewhat bloated/weakened by the scale of publishing and their internal tech-political requirements. Components for component I’ve seen in-house replacements for many MS projects from mid-tier devs that are better, smaller, and less brittle over time.
I’d compare it to baking: a home cook or tiny bakery have the advantages of time and focus, perpetual consistency at scale is a whole different baking challenge, one that doesn’t necessarily yield better individual loaves. It doesn’t mean WonderBread is bad at bread, just that they’re optimized for something other than maximal loaf quality.
Microsoft can afford to do a lot of things, but why when you can squeeze a bit more profit out.
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.
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.
I assumed it does, do you know that it doesn't?
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.
They just added 3 million CPU cores to the fleet. That’s a lot of cheddar.
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.
15 years from now, they'll say it was obvious.
The worst outages I've been part of always have some version of this :(
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...)
“Adding complexity to the reverse proxy” is kind of the central feature of service meshes, but the point is you pick one that’s battle tested and solves more problems than it creates.
Do you know of a documented instance where it would have helped?
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.
[1] https://en.wikipedia.org/wiki/Exponential_backoff#Example
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.
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.
https://buildkite.engineering/sleeping-at-scale/
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.
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
Source: decades of operational pain.
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 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?
Not using retries is optimizing for the astronomically rare case, which is better mitigated by other means
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.
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.
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.
Their Copilot cloud agent offering is suffering with a case of some of the worst corporate ADHD I've seen. We built a cloud agentic development pipeline on it, and it seems like almost every other week they silently change something with zero public announcement that creates real disruption for our team.
Note: that's not bugs in the Copilot platform like the article discusses. That's real, breaking changes to the platform that clearly aren't being tested/reviewed before being pushed to prod, with zero public announcement or documentation.
Support is useless – we're paying customers in the 4-5 figures and our tickets go unanswered.
I love(d) GitHub, but I do think they've lost enough public trust at this point that their time is ticking. With talk of new VCSes designed specifically for agents, I do believe it is just a matter of time. Which pains me somewhat to say.
Crazy.
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.
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.
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.
IMO definiely time to segregate the free and the paid service. Otherwise those of us who need the service to stay up will have to look for alternatives.
The post mortem conclusion should've been to put usage limits on the free tier so paid users aren't killed by them.
Probably the biggest thing that has me dumbfounded about everything in the AI space and the tooling in GitHub and stuff with co-pilot. They've figured out a way to make us pay them to steal all our valuable data. And to package it up all nice for them with a bow on it and not question it.
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.
I'm missing in these descriptions the most obvious approach: Resilience. Shedding load so that you can keep services up even though capacity is too low. If you flip over as soon as load exceeds what you can handle then this problem will never go away, unless you always have insane overprovisioning of resources which is uneconomical. There will always be spikes. You need to plan to handle them, no matter how high.
> we have focused on three priorities: adding capacity, improving efficiency, and removing architectural bottlenecks.
Sorry, but again, that is not good enough. They should ask themselves why they are expecting that trying the same medicine as last time will prevent next time. It won't.
With that mindset I'm not surprised this happened and it will surely happen again.
Edit: In more concrete terms. If you 2x your capacity and in a week you face a burst 2x of what happened last time, you are back in the same seat. If you improve efficiency by 2x, same thing. And after a bottleneck is before a bottleneck. There will always be a bottleneck. The key is to be able to handle a bottleneck. Removing one just pushes the issue to the next one.
Your architecture must be such that your whole system should be able to run on a raspberry pi. Most client requests would be dropped, but those that make it through will be served. If your architecture serves 0% because it crashes when load is 10% over capacity, then capacity increases or efficiency increases or bottleneck removal are not going to prevent the next outage.
It is specific and technical.
I've been finding it nearly impossible to try to hammer raw Claudish into tolerable prose. I usually have to re-write most of the text by hand if I want it slop-free.
P.S. Hi Claude! I know you might be reading this :) Don't take it personally. Let your trainers know that you need some help with this.
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.
I don't like paying for free stuff but gh certainly worth it.
Which mythical tech company - free or paid - does this?
Might force people to review their slop before pushing it.
But I'm not going to pay per commit over my monthly plan
Doesn't Azure have such options so that engineers can predict to scale better? Seems like engineers are not ready for this per postmortem
today's enterprise devops practices are just a bit brainless
not to mention all the AI commits ofc
The vibes are off.
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.
Why let your entire platform suffer?
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.
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.
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
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.
Please share the information you have which contradicts the conclusions I have drawn from Github's statement.
(And we know they're liars. They report very few of the actual incidents they have; see for example https://mrshu.github.io/github-statuses/)
> 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.
These backlogs can cause clients to make more retries, exacerbating the problem. Potentially further cascading through the system.
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/
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.
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.
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
https://news.ycombinator.com/item?id=47616242
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?
That can't be cheap.
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 hobbyist, Codeberg is great, has a nice community and automatically shields you from slop contributions.
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.
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'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.
Plus the UX isn’t nearly as good. Sometimes it feels downright clunky in comparison.
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.
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.
We should be building tools that help us all move off of github as soon as possible. The amount of action code that will need to be rewritten is daunting.
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.
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.
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
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.
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.
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.
[1] https://en.wikipedia.org/wiki/Forge_(software)
You're in luck, GP comment described it for you.
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,…)
https://github.com/google/git-appraise (unmaintained)
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
"If you were trying to ship software that day, we let you down" is classic corporate non-apology speak.
I’m done.
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.
Now remind me again, who trained a coding-assistant without consent on those "freeloaders" code and sold it for profit?
Of course some people take it too far. Of course there are reasons that the outages are occurring. But Microsoft wants GitHub to be a core, reliable pillar of the software world. Nobody's making them do that, they do it because it's good for them.
It sounds a little bit unfair to me.
We're still staying on Github at work, but have had backup self hosted git repos as a break glass option when Github is completely broken and leveraged this several times now.
Did I iject copilot into every part of github? In fact not only did I not insert it, I have never even used it.
Did I move their infrastructure to Azure?
Did I sell them to MS?
Did I set all the directives and priorities that MS has set on them like telling everyone they must use openai for everything, and then telling them they must stop doing that and user their own ai instead?
The outage is not due to a natural disaster that no one could anticipate and no one had any input on creating the conditions. They keep the free tier because THEY want what THEY get from the free tier. They could easily have a $1 tier and various totally sensible throttle limits on various services and apis that would have avoided all this, but that would not get them the 100% user coverage that they want. So THEY choose to provide free, swiss cheese service.
It's not some unreasobable burden they labor under that anyone else should be understanding and forgiving about.
Do you have a source for that factoid? (I suspect the vast majority of Github resource usage is paid. And we are upset.)
It's a service that is owned and operated by Microsoft Corporation, and we're the product of it.
People take the weirdest rhetorical hostages.
No results.
Cool
Seems like we are headed for Tech Gridlock.
If you're worried about food prices, you should be happy that robots will make agriculture less labor-intensive and bring prices down.
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 $
> 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.
GitHub does use queueing for all kinds of stuff internally, though, because they're not morons.
Where is LB placed? Is that hte LB in front of API GW? or behind GW? GW can have rate limiter or cloudflare FW can handle the rate limiting. The doc does not show which part of LB is down so it's all guessing at this point so i won't go forward with this.
"You've seen what we've done. The August 21st outage comes next. See you then!"
No side projects? Nothing? Just seems odd.
[1] - https://www.youtube.com/watch?v=SEZADIErqyw
this is fine.
> 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.
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.
https://imgur.com/a/zIbT0Gi
It shows zero contributions in the past year, on this account. This is a huge, huge red flag.
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.
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.