Yeah, only yesterday I let claude build and deploy me a end to end project that will flicker my lifx light-bulb when commits to any open source project lands. In the morning I saw it stopped around 11 pm PST yesterday. I was wondering why and I was wondering, how easy it is do a complete working project like this in minutes and what is stopping people to do 100s of such project per day. Github wasn't built for this scenario.
Free Github Actions weren't built for this scenario.
Make Github Actions a paid-tier exclusive and this problem goes away.
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.
> 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.
They don't charge you for your own runner but they wanted to. The downtime hasn't really impacted me and not really a reason for me to leave github, but making me pay for using my own infrastructure would quickly encourage me to leave github.
I think a reasonable amount is fine for them to serve as the orchestrator, queue, and control plane for self hosted runners, has to be reasonable though. Think monthly utility service cost to maintain service vs usage.
Is this really the case? Because GitHub availability has been going downhill since way before models hit that critical mass of quality end of last year.
I have not understood, and still do not understand, why everyone locks themselves into github's CI/CD pipeline. It's not hard to set up checks that run on a generic docker setup. I have a home server that I use for all my builds and checks, with a github actions config to run manually if I can't VPN into my home network.
Besides being more reliable, it's just faster to run on a machine you control.
If you're a small/FOSS project, it's not worth the time overhead to set up and maintain and troubleshoot.
If you're a large project, companies generally get more value paying for SaaS and letting devs do dev, rather than troubleshooting Jenkins for the billionth time.
The real value self-host brings is somewhere in the middle, where you need paid-level features with 0 fiat (and can pay in time instead).
There’s a great deal to be said for having (inter alia) matrices, job dependencies, and cross-platform runners already working and available. Docker won’t immediately provide those things.
It's probably the biggest, bestest, hardestest proof of 'worse is better' anyone could think of. The system is so dumb and inconsistent and simplistic it's actually a selling point: 'everyone in my team knows yaml' is an argument I kept hearing, but this conveniently ignores the fact that a) yaml is a serialization format, not a business logic description language b) the values in the yamls are a cursed mix of shell, whatever js variant it is c) actions themselves are mixes of scripts that accept completely schemaless values, so good luck figuring things out (at least in the pre-LLM era, anyway).
It's like everyone collectively agreed that assembly is bad, yes, but building CI/CD in assembly is actually good.
I was just debating if I was going to side step actions altogether for a new build and deployment flow.
I'm at a point where I'm going to set two permanent branches on the remote, one pertaining to each environment. The targets will poll for the latest commit at their configured branch and perform a rebuild internally if a change is detected. Assuming git core ops are still alive, it is possible to keep this running. It's also easy to migrate to a different vendor.
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.
Anything people are building with agentic coding could be called a "house of cards."
It should not surprise people when things start collapsing when there have been little falsehoods and random bits of senseless codes written by agents all over the place.
Basically yes, that's modern day cloud native large scale scalable software. Many smaller software components working together, and sometimes you get a perfect storm of issues or a single point of failure (like DNS) that fails.
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.
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 goes from having a free tier and a premium tier, which works 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.
For us it's not just about reliability, but risk exposure. The last couple of years really changed what our security model looks like. And it's not in public clouds, on SaaS products. LLMs are killing SaaS for sure, not by replacing them but making them a concentrated risk.
Or rather rate limit CI or something. Free repos that don't use large scale LLM activity to trigger a humongous amount of workload onto the github servers don't have to be caught in the crossfire.
Yeah, only yesterday I let claude build and deploy me a end to end project that will flicker my lifx light-bulb when commits to any open source project lands. In the morning I saw it stopped around 11 pm PST yesterday. I was wondering why and I was wondering, how easy it is do a complete working project like this in minutes and what is stopping people to do 100s of such project per day. Github wasn't built for this scenario.
Free Github Actions weren't built for this scenario.
Make Github Actions a paid-tier exclusive and this problem goes away.
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.
> 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.
They don't charge you for your own runner but they wanted to. The downtime hasn't really impacted me and not really a reason for me to leave github, but making me pay for using my own infrastructure would quickly encourage me to leave github.
I think a reasonable amount is fine for them to serve as the orchestrator, queue, and control plane for self hosted runners, has to be reasonable though. Think monthly utility service cost to maintain service vs usage.
Is this really the case? Because GitHub availability has been going downhill since way before models hit that critical mass of quality end of last year.
Why they didn't prompt something like "please make whole system more reliable, don't make mistakes"?
Exactly! Let's keep it light and casual!
Wow I missed the forest for the trees!
This is the...<insert more tokens for this recursively repetitive joke>
These jokes are getting tiresome. They’re not down because they’re using vibecoded software, they’re down because their usage is up 30x year-on-year.
Both things are possible. We don't know that vibecoded software doesn't contribute to the problem.
I have not understood, and still do not understand, why everyone locks themselves into github's CI/CD pipeline. It's not hard to set up checks that run on a generic docker setup. I have a home server that I use for all my builds and checks, with a github actions config to run manually if I can't VPN into my home network.
Besides being more reliable, it's just faster to run on a machine you control.
If you're a small/FOSS project, it's not worth the time overhead to set up and maintain and troubleshoot.
If you're a large project, companies generally get more value paying for SaaS and letting devs do dev, rather than troubleshooting Jenkins for the billionth time.
The real value self-host brings is somewhere in the middle, where you need paid-level features with 0 fiat (and can pay in time instead).
Forgejo actions with a self-hosted runner works amazing for me.
Maintaining Windows and macOS self hosted GH (or GL) runners is a hassle I really don't want to deal with anymore (been there done that).
One reason is it lets you access Windows build machines for free when you no longer have any around.
I would not underestimate how strategically important that will prove to be for Microsoft moving forward.
Because I don’t want to maintain a server and pay for it.
I have a few GitHub actions that have ran for years without issue. You add a yaml file to your repo and it’s done.
As a hobbyist, I’m happy.
I would never do any real work with actions though.
Even if you still use the actions the CI / CD minutes can still happen on a self hosted machine. https://docs.github.com/en/actions/concepts/runners/self-hos...
There’s a great deal to be said for having (inter alia) matrices, job dependencies, and cross-platform runners already working and available. Docker won’t immediately provide those things.
It's probably the biggest, bestest, hardestest proof of 'worse is better' anyone could think of. The system is so dumb and inconsistent and simplistic it's actually a selling point: 'everyone in my team knows yaml' is an argument I kept hearing, but this conveniently ignores the fact that a) yaml is a serialization format, not a business logic description language b) the values in the yamls are a cursed mix of shell, whatever js variant it is c) actions themselves are mixes of scripts that accept completely schemaless values, so good luck figuring things out (at least in the pre-LLM era, anyway).
It's like everyone collectively agreed that assembly is bad, yes, but building CI/CD in assembly is actually good.
Because that model does not scale for teams of developers who need a consistent view of CI health, build health, and PR readiness
I was just debating if I was going to side step actions altogether for a new build and deployment flow.
I'm at a point where I'm going to set two permanent branches on the remote, one pertaining to each environment. The targets will poll for the latest commit at their configured branch and perform a rebuild internally if a change is detected. Assuming git core ops are still alive, it is possible to keep this running. It's also easy to migrate to a different vendor.
Is github built out of a house of cards? How does this stuff keep happening?
GitHub usually says it's because of the increased demand from AI. I didn't believe it until I saw the numbers: https://github.blog/news-insights/company-news/the-august-17...
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.
Anything people are building with agentic coding could be called a "house of cards."
It should not surprise people when things start collapsing when there have been little falsehoods and random bits of senseless codes written by agents all over the place.
Basically yes, that's modern day cloud native large scale scalable software. Many smaller software components working together, and sometimes you get a perfect storm of issues or a single point of failure (like DNS) that fails.
Sort of.
It's on Microsoft Azure.
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.
I'm genuinely amazed by anyone still using github CI for anything serious.
Which alternative do you like?
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.
Yep. We're a huge customer. It hurts. We are making exit plans.
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 goes from having a free tier and a premium tier, which works 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 suspect the same.
For us it's not just about reliability, but risk exposure. The last couple of years really changed what our security model looks like. And it's not in public clouds, on SaaS products. LLMs are killing SaaS for sure, not by replacing them but making them a concentrated risk.
Last time there was an incident like this was 4 days ago.
There are no more excuses to self host. You can now ask Claude to do it for you, given that “coding is solved”.
Or even vibe code your own GitHub at this point.
> There are no more excuses to self host. You can now ask Claude to do it for you
Can’t tell if the irony is intentional or not
Whose agents have escaped this time?
Oh again?
I am using Linear. Some component in Linear showed me the warning. I went to a GitHub PR, there was no warning. Hm.
At this point, a status bar color when gh is down would be enough.
At this point just start charging and get rid of free repos. It's obviously killing the service.
Or rather rate limit CI or something. Free repos that don't use large scale LLM activity to trigger a humongous amount of workload onto the github servers don't have to be caught in the crossfire.
doesnt surprise me
Microsoft should have never been allowed to buy github. A functioning government would have prevented the acquisition.
The entire US economy is tottering due to a lack of anti-trust enforcement.
Even The Economist, an oligarch-friendly magazine, has been hitting the alarm bell on this for over a decade: "America needs a giant dose of competition" https://www.economist.com/briefing/2016/03/26/too-much-of-a-...
There must a top 0.05% of users that account for the vast majority of this bs. GitHub should charge them and serve the majority.
Or just punitively rate limit them