Live data from Hacker News

Incident with Github.com [resolved]

githubstatus.com

851–860 of 1001 posts

Re: Incident with Github.com [resolved]

#851

Earlier quoted context omitted.

Being the _the_ place for open source is what let them dominate the enterprise. Now that they dominate the enterprise, it'd make financial sense to put hard limits on the free tier. It's cynical but it would be foolish to lose that cash machine. It'd open them up for a competitor to slowly build up good will in open source then take them on in enterprise, but right now they are risking losing it all.

Big enterprises are on a different github deployment, so I doubt they are affected by this

Enterprise Cloud was indeed affected by this (as of this morning)

Re: Incident with Github.com [resolved]

#852
post #211

Earlier quoted context omitted.

Because any price at all will immediately cause users to shift to another platform, and GitHub's value is that it is _the_ place to put your code on the internet.

Being the _the_ place for open source is what let them dominate the enterprise. Now that they dominate the enterprise, it'd make financial sense to put hard limits on the free tier. It's cynical but it would be foolish to lose that cash machine. It'd open them up for a competitor to slowly build up good will in open source then take them on in enterprise, but right now they are risking losing it all.

Increasing prices are a sure way to enshittification. It will push people away from github. Many such previous examples

Re: Incident with Github.com [resolved]

#853
post #211

I don't understand why Github hasn't solved this problem with pricing updates. My understanding is they are getting hammered with LLM generated code growing their traffic by over an order of magnitude. So why not rate limit non-paying users and charge for whatever scarce resource is being consumed that is causing them to constantly fall-over? This seems like a basic economics problem.

Because any price at all will immediately cause users to shift to another platform, and GitHub's value is that it is _the_ place to put your code on the internet.

uh, isn't its value that some of us pay them money to have a service?

Re: Incident with Github.com [resolved]

#854

Earlier quoted context omitted.

Luckily we already have a distributed version control system that can take over github: https://fossil-scm.org/home/doc/trunk/www/index.wiki I suppose people can use git too if they ever figure out how to send emails from a dedicated client.

There are plenty of alternatives for git hosting. The last thing which needs to be migrated before we get an exodus off this vibe coded monstrosity is reputation (i.e. github stars) which are inherently sticky.

My main reason for using Github is stars (bookmarking)

Re: Incident with Github.com [resolved]

#855

Almost 3 hours in and still "We are still working to identify the root cause" Can't even view diffs in the web interface! I'm out! I am willing to pay ~$5-10/mo for a reliable host I can swap as painlessly as possible. Mostly just building little static sites and little PWAs, no more than 500mb a repo and 10gb total. Need a repo with PRs and issues, where people can register free account and contribute or raise issue…

I was in a very similar situation and this is what I did: - put Forgejo on a little $5 Vultr VPS (I share the VPS with other things, Forgejo doesn't need much resources. I also added some block storage to host my Docker containers in the Forgejo Docker registry) - got a 8GB ram cheaper Hetzner VPS (you have to wait for their availability) for around 8 EUR and used that to install the CI runner - Use Netlify for hosti…

Similar! I was tired of the outages and crazy runner bills so I just finished moving everything to my own server hosting Forgejo. I've had to recreate a couple things (like a dependabot replacement) but it's been a week so far and it's going well - I haven't had any outages nor have I been finding ways to lessen my Runner billed minutes.

Forgejo has some quirks (like no ability to share workflows between private repos) but I'm happy with my choice so far.

Re: Incident with Github.com [resolved]

#856

The LLM code influx is not the problem. Microsoft mismanagement is: https://damrnelson.github.io/github-historical-uptime/

GitHub's historical uptime page is fake, they backfilled it with 100% uptime going back to 1996: https://www.githubstatus.com/uptime?page=200

Strange. The back button in the UI is disabled once you get back to September 2016. https://www.githubstatus.com/uptime/8l4ygp009s5s?page=40

The earliest recorded downtime for Git Ops I could find is in December 2018. https://www.githubstatus.com/uptime/8l4ygp009s5s?page=32

Re: Incident with Github.com [resolved]

#857

Earlier quoted context omitted.

Well, it would be a mistake on your part to assume that everything in an organization, especially a large one like github, is a reflection of the capabilities of the state of the art in anything (AI, architecture, programming language, organizational management, operations, etc.). It's clear that updating the status page as quickly as possible isn't even something github cares about.

It would be a mistake to judge AI based on the performance of one of its strongest pushers and promoters? Interesting take.

My company is heavy on AI promotion, but many many many people still do things sub-optimally, and many systems are still not well integrated/able with AI.

“The future is here it’s just not evenly distributed”, and that applies inside companies too.

Hard to actually judge without being in the room and knowing the team that owns the incident. And as other said, it’s pretty common IME to have a root cause but slow roll communication of it until remediation has more confidence.

Re: Incident with Github.com [resolved]

#858
post #847

Earlier quoted context omitted.

It's easy from an armchair to say things like they should just get more capacity, or they should segregate free repos onto other servers. But maybe they are doing what you're thinking, and with that churn they get mistakes that cause outages, esp dealing with legacy systems. I've been there (not at GitHub or MSFT).

They do not need to make any technical changes. They could make the change overnight: $1 per repo per month (or whatever). This would stop the aggressive growth that they clearly cannot handle anyway. The question is: are they willing to compromise growth for QoS. So far the answer is a resounding: "no". They are deliberately sacrificing the experience of existing users to gain new ones.

No way I pay $1/repo/month. No way I pay $1/repo/year. I still host and maintain my old code on GitHub, but any free tier pricing update and I jump ship immediately.

Re: Incident with Github.com [resolved]

#859

Almost 3 hours in and still "We are still working to identify the root cause" Can't even view diffs in the web interface! I'm out! I am willing to pay ~$5-10/mo for a reliable host I can swap as painlessly as possible. Mostly just building little static sites and little PWAs, no more than 500mb a repo and 10gb total. Need a repo with PRs and issues, where people can register free account and contribute or raise issue…

Update 16:36 UTC - We identified the problematic component and have taken corrective actions. There are strong signs of recovery but we are still working to completely restore service, with error rates still remaining slightly elevated. We will post further updates as recovery continues. just shy of 3 hours to find the issue

"Strong signs of recovery" is a crazy way to describe the status of a computer system. Wow.

Re: Incident with Github.com [resolved]

#860

Earlier quoted context omitted.

Being the _the_ place for open source is what let them dominate the enterprise. Now that they dominate the enterprise, it'd make financial sense to put hard limits on the free tier. It's cynical but it would be foolish to lose that cash machine. It'd open them up for a competitor to slowly build up good will in open source then take them on in enterprise, but right now they are risking losing it all.

Big enterprises are on a different github deployment, so I doubt they are affected by this

lol
Post reply on HN