Comment by a10c
5 hours ago
My action failed with "Unexpected error fetching GitHub release for tag refs/heads/master: HttpError: Sorry. Your account was suspended"
Which certainly made me shit myself, briefly.
5 hours ago
My action failed with "Unexpected error fetching GitHub release for tag refs/heads/master: HttpError: Sorry. Your account was suspended"
Which certainly made me shit myself, briefly.
It's an eye opener. Think about it - today, it was a mistake. But, what if it really happened? What if you really lost access to all your years of hard work? It's a wake up call. A blessing in disguise to store what matters to you the most locally, backed up offline. Never trust any single provider. Be it MS or Google or Apple. RAID is the way.
People should use something that keeps a local copy of their code and just copies it to Github and to other contributors with a sync process to push and pull changes. Some sort of 'distributed source control system' maybe. Then people would only need a 'hub' to connect to people, and it'd be easier to move somewhere else.
I like how tech seems to be all about stacking more and more turtles on top of each other:
Gosh, it's hard figuring out what changes Lorne made if only we had a system to merge those changes. Enter git
Gosh it's hard figuring out what packages Rachel had to make this work. Enter rubygems/pip/npm
Gosh it's hard figuring out sync these changes across a network. Enter github
Gosh it's hard figuring out how to get those packages working on my operating system. Enter docker
Gosh centralizing our distributed version control software system onto one website is getting really unreliable. Enter fossil(?????)
If we go any further having one computer per business with a sign up sheep is starting to sound pretty fucking attractive.
> Some sort of 'distributed source control system' maybe
The day it broke away and became centralized was when we had a PR + mandatory "Required actions" to merge to main.
What you just described is Fossil. It has an auto-sync feature that makes everything feel distributed.
Just set up a Kubernetes deployment and you’re set.
But as others mention, GitHub’s primary strength is collaboration. If you want decentralized, solve this by creating a decentralized collaboration tool on top of fossil and/or git.
For example, how to do pull requests and code reviews?
1 reply →
This gets tiresome. Github is a lot more than a host for Git repositories. If you want to suggest that people use something else, you need to suggest a replacement that has the features people use Github for.
3 replies →
I recently got my GitHub account suspended for 4 months. When it was finally reinstated, their support just said it was a "mistake".
Proudly self-hosting Forgejo since then.
This happened to me as well—thankfully not my personal account that I use for work, but the organization associated with an open source project I worked on was suspended. It similarly took 2 months for GitHub to restore the organization.
> Our team is currently experiencing an unexpectedly high volume of tickets which has resulted in longer response times than we prefer. We acknowledge the long wait and apologize for the experience.
> Sometimes our abuse detecting systems highlight accounts that need to be manually reviewed. We've cleared the restrictions from your account…
Fully self-hosted IMO can be an overcorrection. The issue isn’t “relying on other people”—it’s relying on GitHub, when they’ve made it clear they don’t care about uptime and they don’t care about support turn-around-time.
RAID is not a backup.
They... Didn't describe RAID? More 3-2-1.
2 replies →
Well yes, my git repositories sit on my laptop, that's the entire point. If github banned my country because its president has a tis, I can push my entire commit history to another company. Same with anyone else who's working on it.
It would be a pain as I'd have to set up a few integrations again, but github is far lower down the risk scale than the vast majority of SAAS providers
A brownout redefined.
ShitHub
https://www.youtube.com/watch?v=LGeOee7x5lY
Good thing I'm wearing my brown pants today.
Same. It's weird how I always find out that GitHub is down before GitHub does. Took 15 minutes before it appeared on githubstatus.com
All these monitoring rules are of the format "when 500 errors > baseline for x minutes". Otherwise you'd have monitoring alerts every second. So it is normal for users to already see errors before github officially counts it as an outage.
> All these monitoring rules are of the format "when 500 errors > baseline for x minutes". Otherwise you'd have monitoring alerts every second. So it is normal for users to already see errors before github officially counts it as an outage.
Is it true that official service status pages are updated automatically?
1 reply →
You'd expect them to be monitoring more than just the HTTP response codes from user requests for precisely this reason.
If the first they hear of an outage is when user requests start to fail, then that's a failure in their monitoring as well.
But effective monitoring is harder than people assume.
7 replies →
In a high performance service with good maintenance and upkeep, you page for all 500s. A noisy pager forces the team to fix the 500s.
Maybe the Github Actions infrastructure isn't run like that.
edit: my oncall rotation notified on all 500s, 24/7, not just rates - https://news.ycombinator.com/item?id=48279262
24 replies →
I'm not arguing with what you're saying, but it does make me wonder: What exactly is the point of the status page, if "it is normal for users to already see errors before GitHub officially counts it as an outage"?
Is it more so to have something to link to for managers who aren't using the service have a pretty bar to look at and feel like they are "doing something"? Or is it more of a kind of a way to prevent confirming what you already suspect to be true. E.g. "Huh. Me and Jim are seeing problems. How about you Tom? Oh wait, crud. The service page is confirming it's down now. Never mind! Who wants coffee?!"
1 reply →
More likely that 'update the Status site' lives a long way down their incident response plan, and they have alarms going off well before that
yeah I mean a company the size of GitHub certainly can’t be expected to have enough staff to walk and chew gum at the same time
1 reply →
it should be automatic tho. Probably isn't so they can at least get the one nine on availability
1 reply →
That's the time taken by Head of PR approval.
/i
> githubstatus.com
There's a threshold. It shows only once 1000 users complain.
> It's weird how I always find out that GitHub is down before GitHub does
No, it's not. Official updates = potential SLA penalties. Always requires approval.
This is the most plausible reply.
Yes, Thais can be be really frustrating when you’re trying to get work done. There needs to be more competition and better alternatives and the LLMs need to offer easier connection to these alternatives.
What do the Thai people have to do with this? :(
Pretty sure that they wanted to write "this", typed something different by accident, and auto-correct struck.
1 reply →
Reminded me of the "Thai Fighter" joke from family guy's star wars spoof lol