What I find problematic, especially for teams that rely on GitOps and GitHub being (relatively) stable, is the fact that GitHub's status page can't be relied on. You arrive at the conclusion, "this must be GitHub," but the status page rejects the notion, and so you go digging. That can lead to a lot of toil and wasted time, in addition to sideways looks paired with comments like, "but status shows green."<p>A sick person with symptoms is clearly sick, but sometimes they're asymptomatic. That's what the GitHub status page has become. When it's red and showing problems, you know you have problems. When it's all green? You know you MIGHT have problems.<p>That can make outages like this harder to triage, since reality is a black box.
> "this must be GitHub," but the status page rejects the notion, and so you go digging<p>Don't know about you but at this point I've learned to recognize and ignore GitHub issues even when they haven't admitted to it yet
Github is fast in updating their status compared to other companies. Amazon has to be bombed, on fire, and in the news before their status page shows anything about any ongoing issues.<p>I assume these companies have some kind of uptime guarantee in their contracts, because they seems to care more about covering their asses than about informing customers.
Comparing one shitty set of standards to another shitty set of standards… hmm
No they aren't, we can see outages coming 20+ minutes before GH reports them.<p>We have outages on our books that they never reported even after we ticketed them.<p>They cook the stats like an inner city police department.
This is why you ignore everything for at least 30 min before starting to investigate...
I can imagine a lot of people moving to OCI instead of GitOps
It looks like today there was maintenance scheduled to deprecate support for certain categories of SSH keys: <a href="https://github.blog/changelog/2026-09-22-security-improvements-for-ssh/" rel="nofollow">https://github.blog/changelog/2026-09-22-security-improvemen...</a><p>> November 4, 2026: We’ll have a brownout of the removal of the ssh-rsa signature type (i.e., RSA keys using SHA-1) and the diffie-hellman-group-exchange-sha256 key exchange algorithm.<p>I guess something went sideways.
<p><pre><code> - - > i wake up - -
| |
| V
github has an outage</code></pre>
Do you fall asleep every time GitHub has an outage? Are you narcoleptic?
Point of clarification: do you work at GitHub?
A manager might say you need to stop waking up.
<p><pre><code> def is_github_down(day):
return day[-1] == "y"</code></pre>
Our deploys are tied to GitHub actions and it is becoming a liability at this point. What alternatives do people use? I mean for FOSS there are some decent stuff but we need a reliable provider for private repos.
This is exactly why I don't understand companies (like some of my clients) that move from self hosted Jenkins to GH Actions.<p>You're literally replacing a well designed resilient system with a single point of failure run by a different company...
I get to tell my manager it's github's fault.
> a well designed resilient system<p>Wait, Jenkins?
We use GitLab where I work. The only problem is it calls pull requests "merge requests," and I don't think I'll ever get used to saying "MR" instead of "PR."
Self-hosted Forgejo with a bunch of runners might also be interesting for you. The workflow syntax is _almost_ identical to the github one.
Self hosted Jenkins, been working wonderfully.
My deployments are tied to their container registry, so I'm equally screwed... Been thinking of going back to Dokku, I started working on a third wrapper around Dokku (yeah, I've literally done this twice already), and then self-host and self-provision... I honestly thinking seriously about this.
Forgejo backed by Woodpecker CI running on Kubernetes (Talos) has been amazing! Ditch Github Actions syntax for the simplicity of Woodpecker and containers. You'll thank me later.
Genuine question: if you're hosting private repos, is self-hosting an option?<p>Gitea Enterprise would be worth looking at.<p><a href="https://about.gitea.com/products/gitea-enterprise/" rel="nofollow">https://about.gitea.com/products/gitea-enterprise/</a>
Buildkite with self hosted runners
I self-host with GitSocial.<p><a href="https://gitsocial.org/" rel="nofollow">https://gitsocial.org/</a>
Some of our deploys use CircleCI instead, but they were still broken because they couldn't checkout from Github.
We're shipping private repos for Tangled very soon (tangled.org). Shoot me an email anirudh@!
Post receive hook on a bare git repo with gitolite for access control.
self hosted forgejo has been my saviour. im thinking in acquiring a new NUC server to increase compute and storage to my homelab to add some new runners
gitea is amazing.
You don't even have to migrate off GitHub if you don't want to.<p>Begin by refactoring the deployments so they're driven by checked in shellscripts, that accepts a git reference to deploy (prefer immutable commit SHAs over mutable branches/tags). Make it use the stuff it already has checked in, and make the actual GitHub Actions stuff as small and concise as possible, ideally each "run" should just call a shellscript with the git reference.<p>Then move so the deploys happen not on GitHub Actions itself, but on a "intermediate deploy host" that has the source code and access to the credentials you need, and make this host have one secure entrypoint, where someone (or something) can enter and run shellscripts, after pushing their code as a normal git push. Then switch so the deploys from GitHub Actions instead use this new host to do the deploys. Lock down this host hard.<p>When GitHub and/or GitHub Actions go down, the developer responsible for deploying stuff, should be able to get temporary git and ssh access to this host, can push any git data straight to the host, and their user on this host can run the deploy scripts. Keep in mind that nothing in your deployment process should depend on stuff that isn't also available on this "deploy host", if you have multiple synced repositories and so on.<p>Now things mostly work the same as people are used to, with the added benefit that when things go down again (like next week), you'll still be able to continue to deploy stuff.<p>I've done this refactor/migration for tens of companies in the last year, more or less following this exact template for all of them, with no issues reported from either of them, but lots of praise :)
[flagged]
Git itself usually works, but we gave up on GHA and use <a href="https://www.rwx.com/" rel="nofollow">https://www.rwx.com/</a> for tests, previews, and deployments. It’s 2x to 10x faster than GitHub Actions and testing uncommitted changes on real CI infrastructure is a total game changer.
Finally a GitHub outage during European workday. Yaaay.
I was thinking I'm going crazy with me ssh keys not working on both of my machines.
Can't even pull no more using my key. That's a new low, I'm used to the website being janky nowadays but this is seriously essential
At least they have a very clear error message so you know what is going on.<p>> git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.<p>Please make sure you have the correct access rights
and the repository exists.
Just rolled new keys and though I'm going crazy that it's not working
they marked incident with Pull requests, Git operations and issues - but i don't see any outage in the bars for today other than pull requests? what's the point of showing uptime there then? <a href="https://mrshu.github.io/github-statuses" rel="nofollow">https://mrshu.github.io/github-statuses</a> is more reliable than the official github status page.<p>new incident with actions now - <a href="https://www.githubstatus.com/incidents/h02n9572mx9y" rel="nofollow">https://www.githubstatus.com/incidents/h02n9572mx9y</a>.
Can't they just... sell github back like when the germans sold the nuclear plant back to mr burns?
Pretty good timing now that Rails has released a security update :|<p><a href="https://rubyonrails.org/2026/11/4/Rails-8.0.5.2-and-8.1.4.1-have-been-released" rel="nofollow">https://rubyonrails.org/2026/11/4/Rails-8.0.5.2-and-8.1.4.1-...</a>
Temporary workaround is to do<p>git config --global url."<a href="https://github.com/".insteadOf" rel="nofollow">https://github.com/".insteadOf</a> git@github.com:<p>so it pushes / pulls using HTTPS<p>when things are back to normal run:<p>git config --global --unset url."<a href="https://github.com/".insteadOf" rel="nofollow">https://github.com/".insteadOf</a>
It’s kinda funny that GitHub having issues continues to make HN front page.<p>Perhaps these types of posts should just be pinned at this point.
Why do we need centralized CI? We just need a gate to make sure the code passes the right checks before we move the tip.
Well, at the very least, that gate needs to be centralized in some way, right? Unless ... are you suggesting using a blockchain ledger for that?
I think blockchain ledger wouldn't be enough, there needs to be AI agents on top of that, that combined with some kind of harness layer, plus, ideally agents gossiping with each other and sometimes fighting with each other to get best results.
That's the idea behind Tangled's spindles.
because it's simpler.
For a moment I thought my ssh key got breached. Fricking hell Github!
<a href="https://GiveUpGithub.org" rel="nofollow">https://GiveUpGithub.org</a> - why and how to ditch GitHub.
Same old same old.<p>What were the 60'000 people exiting Microsoft doing if not improving Github?
The day GitHub will no longer be free is approaching... they just can't support the abnormal amount of things being pushed rn
For most people here GitHub <i>is already a paid platform</i>. Our companies rely on it as a core part of our development workflows, and we pay a decent bunch of money for it. If it was <i>only</i> the free part of GH having issues, it wouldn't get even remotely near this kind of exposure.<p>Developers are expensive. If I can't ship a feature on time because GitHub issues keeps forcing me to switch to different tasks to work around git/PR/ticket/Actions downtime, then that costs my company real money - despite <i>us</i> not being the source of the AI DDoS that GitHub has happily been welcoming.<p>To me, the situation is very simple: either 1) rein in the AI deluge, or 2) isolate paying customers from it, or we'll move to an alternative.<p>For businesses the current state of unreliability would be unacceptable if it was completely free, the fact that it is actually paid just adds insult to injury.
actions still don't work correctly
Github only has issues on days that end in Y!
There are two more incidents:<p><a href="https://www.githubstatus.com/incidents/xr3myzj7ms51" rel="nofollow">https://www.githubstatus.com/incidents/xr3myzj7ms51</a><p><a href="https://www.githubstatus.com/incidents/h02n9572mx9y" rel="nofollow">https://www.githubstatus.com/incidents/h02n9572mx9y</a><p>Get your act together, clowns.
The outage was quite short
I miss working with a self-hosted gitlab instance.
At this point, even when there isn't an incident, push/pull have been so unreliable as to fail about 30% of the time.<p>I can live with the occasional outage but this is a constant problem.
git clone works sometimes, sometimes not.
I managed to push a commit over ssh but then the client threw an error before the push fully completed. I can see the commit on the web, but my client still thinks it isn't pushed. And now when I try to fetch I get "permission denied" after a long wait, which is scary. I first thought something got hacked.<p>Maybe they need a better AI model for their vibe coding. That'll fix everything, right? At least that's what my friends keep telling me when I say that the free LLMs I played around with a bit are incredibly dumb.
These days, perhaps, normal undisrupted operation should start counting as an incident...
Again and again?
too much slop got them
Another incident. Last time we had one was 5 days ago [0]<p>It's up to you if you want more of this instability. Perhaps you should consider a self-hosted alternative.<p>[0] <a href="https://news.ycombinator.com/item?id=50307843">https://news.ycombinator.com/item?id=50307843</a>
[flagged]
Why haven’t they asked an AI agent to fix all their bugs yet? /s
Just set up a Gitea instance, pushed my code and switched my deployment script to it. Took 30 minutes. Github pulls still aren't working.
GitHub outages can be a drain on productivity.
If your stack is pulling artifacts from GitHub, and this consistently fails during GitHub outage, you can consider having a file-cache in between.<p>Some of our customers unexpectedly started using the service we're running as a file-cache around GitHub to mitigate GitHub outages.<p>We wrote about this use case in our blog: <a href="https://www.stablebuild.com/blog/protect-your-builds-from-github-outages-with-a-file-cache" rel="nofollow">https://www.stablebuild.com/blog/protect-your-builds-from-gi...</a>