It makes sense but in a post AI world - what is of value? Not the software itself, but data and network effects. MS needs to move from a world where their proprietary software makes money, to one where they enable a captive network and have data; Github provides both.

So maybe them providing service at literally all costs to themselves is a smart strategy long term.

I don't see the connection. Pricing may effect their long term prospects, but I don't see any evidence these issues are being caused by a shortage of metered / allocated resources. They should have access to as much Azure compute as necessary.

> This is likely a pricing failure.

They wanted direct access to the repositories for other purposes than serving the customer. Such as training data for copilot, and who knows what else.

Pricing low helped ensure access to that data.

> This is likely a pricing failure.

Problem is while we have a visceral feel for what the "value" of GitHub is to human users for human usage, I'm not sure we have a feel for what the value of the agentic equivalent is.

IMO it's probably very high on paper if you think through what kind of work is unlocked at agent speeds, provided you have a very capable work-execution fabric.

But since we're anchored to human pricing, whatever they propose will feel expensive.

solopreneurs were fine - they were self-limiting.

slopreneurs are the issue

I was very excited about this comment until I got to this part:

> That's a seriously insane number to keep up with at GitHub's scale.

What exactly is it about GitHub's workload that makes us feel like the specific 23k things happening in that slice of one second are tantamount to insanity? In my experience, much of GitHub activity is changing labels on issues and posting plaintext comments.

Technically speaking, this rate of things happening per second is well within the territory of what one large server can handle. I know it sounds wild to imply that we could run all of the GitHub public cloud off a single machine, but how crazy is it in reality when we start to consider the actual I/O bandwidth that is available in a leading edge server platform? All of VisaNet circa 2009 could run off a single mainframe. That's global. It is plausible they still operate this way.

Virtually 100% of the aspects of GitHub that would quickly saturate I/O on the transactional core can be offloaded to horizontal systems like blob storage and CDNs.

It is huge scale, but on the other hand, almost entire GitHub although huge, is made of isolated islands of data (repositories). This is relatively easy to scale. Extreme example would be dedicated server for each repo and its Actions with their own isolated state.

I’d call it impossible if they weren’t already (mostly) doing it

I'm sure they have KPIs, and I wouldn't be surprised if one of their KPIs is % growth in agentic/AI-driven actions.

Be careful what you wish for, because we might get a toll system for humans instead.

They probably had a redistribution of free-tier and paid-tier usage in the last year-ish.

Just backseat gaming but a lot of those issues could probably be solved if they'd (temporarly) reduce the free tier. I'd say simply dropping Actions from it would reduce the load by a lot because then most vibe coders wouldn't bother integrating a CI/CD and either just use local pre-commit scripts or stop using those entirely. Not using a CI also drops the requirement for using PRs on solo-dev projects so they might also reduce load there.

They made the judgement call to make private accounts free before the onslaught of AI. Now every coding agent is using GitHub as their file system backend and pushing it to limits no one has heard of.

If Microsoft had brains they would leverage it to become the de facto file system for all ai agents before cursor or anthropic figure it out.

I do agree they were unreliable before, I even moved my current org to GitLab because of it.

That being said, they are definitely even less reliable now due to demand.

You say “they” as there is a single coherent mind in this case. In the large orgs there are a lot of little independent minds doing their little things, barely producing coherent result through shared incentives.

In this case most simple explanation is inaction. Yeah, it was coming, but nobody was exactly in position or cared enough to do something about it.

Presumably, they still want the free tier to help acquire new customers?

You could say they should separate the human users from the slopsters in any tier. This could be done with some quota/rate limiting model.

But, if they are either on the fence or believing that agent-based development is the way forward, then that new reality is the one they would need to support. Cutting it off will send those customers elsewhere.

And, if you've managed to handle the new workload, it is basically in the noise to also handle artisanal human developers in the background on the same solution...

They have that. I might be wrong, but I don't think they're having these issues with their enterprise offering.

AI is being brute forced everywhere. The impact analysis for everyone is, shit will break but we can use AI to fix it.

> GitHub are too scared to do that after the backlash around charging people for their own runners, but this would be a very different thing, simply stop giving free actions to people who have never paid them a penny.

I had no idea they charged you to run your own runner. I am immediately of the opinion that is wrong.

Conversely, I would have no issues if GHA become a premium product. Or maybe "your actions only run when we have spare compute". I've personally given Github money (back when private repos cost $$) and wouldn't be concerned about doing it again.

That is to say, I think you've nailed it.

It isn't just that they wanted to charge for using your own action runners. It's that the price was almost as much as using GH's hosted action runnners. Which didn't even include the cost of hosting your own runners.

I think removing the free tier altogether would be a bad move, especially given that some important open source projects rely on it. But they could possibly lower some of the limits, especially for new accounts, with a way for open source projects to apply for more, and maybe have an automatic scale up for projects that are more popular, by some metric. And maybe limit the free tier to public repos, and maybe even only repos that use an OSI approved license or something.

Likely easier said then done, but why not separate infra out from shared vs dedicated hosts? Something like, actions will still run but at some degraded capacity, where actions and PRs are still at least functional.

My company has heavy handily moved from self-hosted version control system to github and now we’re suffering more outages. Though the self hosted system had less features, and we needed to maintain our own jenkins infrastructure for CI/CD, at least we really only suffered from very major cloud-provider level outages

worse than this is that if you fork a repo that has actions, the actions will run on your account as well - which is completely unnecessary. I have all sorts of stale forks that are just churning away with actions that I dont care about at all because I am not getting charged.

The solution, of course, is not to simply start charging for all actions, because then everyone would wake up to all sorts of mystery charges. They'd need to notify that forked actions would be turned off and then opt-in for paid actions.

They already have a free tier cap, I believe around 100 action minutes per week or something like that.

(I know because I recently hit it)

Wow I missed the forest for the trees!

Why does everything work perfectly for a week after an outage is fixed? Usage is still 30x and even higher because everyone catches up from the downtime.

Sounds more like a bloated, vibe coded stack that has to be unclogged every 2 weeks.

Both things are possible. We don't know that vibecoded software doesn't contribute to the problem.

From what I understand, it's mostly because Azure is a huge dumpster fire

Right, the added value of being able to access, build, and publish releases for Windows, macOS, and Linux on BOTH x64 and ARM cannot be overstated

you misunderstood the comment you replied to. They were saying any day without issues/problems/failures, not Github Issues.

I do want to check that a PR is green before merging, but I don't want to run CI on every pushed commit

To me, the answer is in the part of the comment you stopped quoting "given that “coding is solved”."

Not really hard to understand code is a arbitrary commodity and anyone can grab a cloud model and push code and hook into ci, then have no idea theyre triggering rebuilds everytime they rename their todo apps title.

I have a noninformed thought on this... I think a lot of these issues are actually because they're not on modern Cloud yet.

I think GitHub was rolling everything themselves when Microsoft bought them. Ever since, MS has been working to strategically shift to Azure but that's a difficult and careful process that takes time.

In the meantime, the AI boom hit and usage went through the roof, crippling aging non-scaled infrastructure that hasn't had a chance to be modernized yet.

A lot of issues might very well be "we broke something while migrating", but I think a lot are also simply capacity issues on legacy.

So a house of cards built on a foundation of shifting sand

GitLab CI, BuildKite, Semaphore, Concourse (development started up again, last release was two weeks ago)...

GitHub Actions is only OK for relatively simple CI needs, or if your project is open-source and you enjoy having free CI. No major professional/enterprise CI need should depend on it.

So I see an interesting side effect of all of this in your comment. The groupthink seems to conclude that the root of GH's issues are: - A dramatic increase in its traffic due to vibecoding - Azure just generally not being very reliable

Now, if you're not a paying customer, maybe you just ignore this and chalk it up to "I'm getting what I paid for". And if you're a paying customer, you migrate away. What happens to GH then? Well, you (and other paying customers) are probably only a small part of the first of the identified causes, and not at all a contributor to the second. So it's not like you moving away will make GH more reliable, but it does lessen MS's motivations for fixing things: GH as a business unit works by having a free tier and a premium tier and that's fine as long as the profit from the premium tier exceeds the cost of the free tier.

THat's long winded way of saying: I wonder if you/other paying customers leaving is the real start of a GH death spiral. Less paying customers == less MS investment == less paying customers == less MS investment, etc.

I think we can just use the orange status bar for that.

Thank you. Agree, that was not the intention