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."
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.
That can make outages like this harder to triage, since reality is a black box.
> 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.
I guess something went sideways.
rarismatoday at 10:48 AM
- - > i wake up - -
| |
| V
github has an outage
eknkctoday at 10:23 AM
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.
thesdevtoday at 10:09 AM
Finally a GitHub outage during European workday. Yaaay.
sognetictoday at 10:14 AM
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
cashbreakertoday at 10:42 AM
I was thinking I'm going crazy with me ssh keys not working on both of my machines.
Can't they just... sell github back like when the germans sold the nuclear plant back to mr burns?
gowthamgts12today at 5:46 PM
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? https://mrshu.github.io/github-statuses is more reliable than the official github status page.
At this point, even when there isn't an incident, push/pull have been so unreliable as to fail about 30% of the time.
I can live with the occasional outage but this is a constant problem.
znpytoday at 4:22 PM
I miss working with a self-hosted gitlab instance.
chinathrowtoday at 10:13 AM
git clone works sometimes, sometimes not.
grishkatoday at 10:57 AM
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.
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.
dude250711today at 10:33 AM
These days, perhaps, normal undisrupted operation should start counting as an incident...
eshertoday at 10:10 AM
Again and again?
dankobgdtoday at 2:26 PM
too much slop got them
rvztoday at 11:02 AM
Another incident. Last time we had one was 5 days ago [0]
It's up to you if you want more of this instability. Perhaps you should consider a self-hosted alternative.
Why haven’t they asked an AI agent to fix all their bugs yet? /s
fredstedtoday at 11:14 AM
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.
malikoliviertoday at 11:09 AM
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.
Some of our customers unexpectedly started using the service we're running as a file-cache around GitHub to mitigate GitHub outages.