Rendered at 16:25:33 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
gophigure 1 days ago [-]
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.
jeroenhd 1 days ago [-]
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.
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.
deathanatos 17 hours ago [-]
> Github is fast in updating their status
Github's status page is incredibly slow in comparison to the status page Github themselves used to have, which had several key metrics of various systems that would update in real time, and when they did have a (comparatively rare) outage, would usually have at least one metric going "yeah, something is wrong".
sleepybrett 23 hours ago [-]
No they aren't, we can see outages coming 20+ minutes before GH reports them.
We have outages on our books that they never reported even after we ticketed them.
They cook the stats like an inner city police department.
beardedetim 18 hours ago [-]
Me and a colleague were just ranting about how there's no way in hell Actions has 99.6% uptime but yet that's what their status page says. Maybe it's just bias and I am only remembering the minutes that it's down what feels like every week or multiple times a week. But I'm suspicious of their stats, even if they declare an incident on the status page.
chanux 22 hours ago [-]
Not fraud from a legal point of view I guess /s
giwook 23 hours ago [-]
Comparing one shitty set of standards to another shitty set of standards… hmm
ozyschmozy 22 hours ago [-]
> "this must be GitHub," but the status page rejects the notion, and so you go digging
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
arccy 1 days ago [-]
This is why you ignore everything for at least 30 min before starting to investigate...
(Perhaps its time to consider an alternative to github, or at least a mirror)
chrisjj 16 hours ago [-]
Each status page update requires preapproval by the PR dept.
defraudbah 19 hours ago [-]
show me one status page that's reliable, it turned into smoke and mirrors
solyin 19 hours ago [-]
downforeveryoneorjustme.com is a high level way to gather that data
thwarted 18 hours ago [-]
Extremely high level, and mainly merely "is the site accessible". However, github having issues with "issues" or "pull requests" is a functionality, not an accessibility, degradation, which can often only be discovered by actually trying to perform the action/use the functionality and comparing the result to he expected result.
c0rruptbytes 1 days ago [-]
I can imagine a lot of people moving to OCI instead of GitOps
stryan 1 days ago [-]
OCI layering on top of running systems a la bootc? or OCI as the desired state storage for CM?
stackskipton 1 days ago [-]
SRE here, OCI for storing deployment config information, most of time, Kubernetes manifest files/Helm Charts.
stryan 23 hours ago [-]
Gotcha, that's what I figured but I was still curious. I've got a side-project that was originally designed for traditional GitOps but got OCI support as a feature submission from a user. I've been seeing more usage of the OCI backend these days and originally figured it was a side-effect of the project domain (Podman Quadlets) but maybe it is an over all field shift.
bdsa 23 hours ago [-]
In the last couple of weeks, I've been moving a deployment stack off ArgoCD pointing at Git, and ended up settling on Flux fetching OCI artifacts from ECR. The artifacts are built and pushed by GitHub Actions. It seems like a nice way to "have GitOps" without needing GitHub to be up all the time.
c0rruptbytes 10 hours ago [-]
I think so, Argo CD appsets are even getting an OCI generator in the next release (3.6)
ECR just seems to work really well for most people and IAM is nice compared to Github Apps + rate limits
> 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.
igleria 1 days ago [-]
hey how much do I owe you for this INCREDIBLY important information? This is not sarcasm btw.
a-squirrel-comm 1 days ago [-]
nothing :) hope they'll release a statement soon, this is was an assumption on my side, it might be totally wrong. I had intermittent issues with basic git pull/push ops locally so I went to dig a bit. ps: if you do have money to spare, consider donating to the EFF (https://www.eff.org) though B)
DanielHB 1 days ago [-]
hah I was wondering why I was getting invalid key errors from github
igleria 1 days ago [-]
thanks a bunch! will do.
qtqtqt 1 days ago [-]
How to check if one's SSH keys are still compatible?
dist-epoch 1 days ago [-]
if any of your SSH key files are bigger than 500 bytes, you should rotate them
matja 1 days ago [-]
Even mldsa44-ed25519?
SkiFire13 1 days ago [-]
Bigger or smaller?
mschuster91 1 days ago [-]
EC keys should be much smaller... this is only valid for id_rsa SSH keys
anamexis 1 days ago [-]
That’s the point.
pksunkara 21 hours ago [-]
If this is truly the cause of the outage, then the incident looks like a result of GitHub's own vibecoding instead of the increase in usage.
Disclaimer: I am building a code forge myself
shawabawa3 20 hours ago [-]
That's not a disclaimer it's just an ad
alala-lala-lon 20 hours ago [-]
[dead]
rarisma 1 days ago [-]
- - > i wake up - -
| |
| V
github has an outage
dodslaser 1 days ago [-]
Do you fall asleep every time GitHub has an outage? Are you narcoleptic?
shepherdjerred 23 hours ago [-]
You have it wrong. GitHub goes down because they fall sleep
GrantMoyer 1 days ago [-]
Point of clarification: do you work at GitHub?
Chris2048 1 days ago [-]
Perhaps they are a process/thread?
binsquare 1 days ago [-]
A manager might say you need to stop waking up.
gib444 23 hours ago [-]
def is_github_down(day):
return day[-1] == "y"
sigmarule 14 hours ago [-]
All will be solved by tomorrow!
lta 21 hours ago [-]
It must be Tuesday, that's why
eknkc 1 days ago [-]
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.
stack_framer 1 days ago [-]
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."
jaapz 1 days ago [-]
Why are all you github people pulling on your requests?
I am requesting to merge my changes into the main branch.
crote 23 hours ago [-]
Because in the good old days when git was still distributed, a merge often started with sending someone an email to obtain your newly-coded commits via `git pull`ing your "gpu-drivers-for-linus" branch from some URL pointing to your personal GitWeb install. In other words: it was a request to pull your code.
Similarly: Why are the Gitlab people so happy to merge? Where is my "Rebase Request", "Squash Request", or "Cherry-pick Request"?
ajasmin 17 hours ago [-]
You can still do this on a GituHub PR. Pull the branch locally, read the code, try things out, rebase onto main…
Once all is good, push into remote HEAD and GithHub should auto-close.
Though, larger project tend to leave the final upstream merge to GitHub itself. Better access control and it’s easier to serialize merges through a single queue for very active projects.
chrisweekly 22 hours ago [-]
good bit of lore.
related tidbit: in git, "pull" is basically shorthand for "fetch + merge".
dutchbart 1 days ago [-]
Or you are requesting me to pull your changes into my branch.
hhh 1 days ago [-]
I have the opposite
Roark66 1 days ago [-]
This is exactly why I don't understand companies (like some of my clients) that move from self hosted Jenkins to GH Actions.
You're literally replacing a well designed resilient system with a single point of failure run by a different company...
hiccuphippo 1 days ago [-]
I get to tell my manager it's github's fault.
Chris2048 1 days ago [-]
> a well designed resilient system
Wait, Jenkins?
iamjake648 21 hours ago [-]
Like with all things, it really depends on having someone competent stand it up and run it. I think we've already reached the point that this is totally worth it for mid-sized companies as opposed to giving MS money for GHA.
saturn_vk 1 days ago [-]
Self-hosted Forgejo with a bunch of runners might also be interesting for you. The workflow syntax is _almost_ identical to the github one.
SkiFire13 1 days ago [-]
Some of our deploys use CircleCI instead, but they were still broken because they couldn't checkout from Github.
pelagicAustral 1 days ago [-]
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.
misswaterfairy 1 days ago [-]
Genuine question: if you're hosting private repos, is self-hosting an option?
Honestly, not really wanna deal with self hosting it. Would rather pay for a decent service at this point.
import 1 days ago [-]
There is already a blacksmith sh if you don't want to selfhost your runners. Or codeberg as a full solution if I am not mistaken.
michaelbuckbee 1 days ago [-]
+1 for Blacksmith. You need to have a Github org to use it as it won't work on personal accounts, but it feels like a magic want that just makes runners 2x as fast.
I have it for all my stuff (dozens of repos and hundreds of PRs/builds per week) and it's only once in the last year that I've exceeded the free resource levels. I don't know if it's just extra capacity or they're burning VC dollars in the hopes of inspiring posts like this, but either way I feel like I'm taking advantage of them at this point.
booi 18 hours ago [-]
But doesn't Blacksmith piggy back off of the Github Actions control plane? Outages will just spread to Blacksmith
crote 1 days ago [-]
Codeberg only allows F/LOSS software, for most companies that's a dealbreaker.
tcfhgj 1 days ago [-]
Private projects usually are not owned by companies
crote 23 hours ago [-]
Your proprietary personal hobby project doesn't need an entire publicly-accessible Forge, it can just live on your local drive or home server. It is also not critical enough that GitHub occasionally being down is a big deal.
If you're looking for a publicly-accessible Forge SaaS for your private repos and are willing to pay for it, you are almost certainly a company developing proprietary software.
bonetruck 1 days ago [-]
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.
paaloeye 1 days ago [-]
How do you run Docker containers inside your K8S? Let’s say you need a test database or test ClickHouse???
I use Jenkins too, however any pipeline starts by checkout from github, so it failed this morning just the same.
karolist 24 hours ago [-]
Same for me, ssh access was intermittent, but at least I have reliable local builds when GitHub actions is out but access works. With AI running Jenkins is not that hard. I build large cuda containers so cost alone ruled out hosted builds for my usecase. There's a bit of update churn but nothing broke so far. I ran around 2000 builds last year. I run it on epyc 7v12 128gb ddr4 host.
Which is 4x the price of github, _plus_ the cost of the runners on top of it.
It's a great service though
myaccountonhn 1 days ago [-]
Post receive hook on a bare git repo with gitolite for access control.
rozularen 1 days ago [-]
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
icy 1 days ago [-]
We're shipping private repos for Tangled very soon (tangled.org). Shoot me an email anirudh@!
import 1 days ago [-]
gitea is amazing.
raddan 1 days ago [-]
Seconded. Also very easy to set up. I’ve been running it for years, along with webhooks to kick off testing and website deployment jobs. I especially like the swagger browser that generate API calls for you to try in curl. I use the API pretty extensively.
embedding-shape 1 days ago [-]
You don't even have to migrate off GitHub if you don't want to.
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.
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.
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.
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.
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 :)
infra_tinker 1 days ago [-]
[flagged]
jelder 1 days ago [-]
Git itself usually works, but we gave up on GHA and use https://www.rwx.com/ 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.
thesdev 1 days ago [-]
Finally a GitHub outage during European workday. Yaaay.
nope1000 1 days ago [-]
Although it is lunchtime :/
y-curious 1 days ago [-]
Isn’t most of the European workday lunch time? :P
I joke, the QoL is really nice
sognetic 1 days ago [-]
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
ayhanfuat 1 days ago [-]
At least they have a very clear error message so you know what is going on.
> git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
chinathrow 1 days ago [-]
That's standard git, not coming from GH.
1 days ago [-]
b1tshift 1 days ago [-]
Just rolled new keys and though I'm going crazy that it's not working
cashbreaker 1 days ago [-]
I was thinking I'm going crazy with me ssh keys not working on both of my machines.
For a moment I thought my ssh key got breached. Fricking hell Github!
colek42 1 days ago [-]
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.
falcor84 1 days ago [-]
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?
nalekberov 1 days ago [-]
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.
icy 1 days ago [-]
That's the idea behind Tangled's spindles.
nalekberov 1 days ago [-]
because it's simpler.
feukon 1 days ago [-]
The day GitHub will no longer be free is approaching... they just can't support the abnormal amount of things being pushed rn
crote 1 days ago [-]
For most people here GitHub is already a paid platform. 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 only the free part of GH having issues, it wouldn't get even remotely near this kind of exposure.
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 us not being the source of the AI DDoS that GitHub has happily been welcoming.
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.
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.
gowthamgts12 23 hours ago [-]
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.
What were the 60'000 people exiting Microsoft doing if not improving Github?
giwook 23 hours ago [-]
It’s kinda funny that GitHub having issues continues to make HN front page.
Perhaps these types of posts should just be pinned at this point.
1 days ago [-]
misnome 1 days ago [-]
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.
w3ll_w3ll_w3ll 1 days ago [-]
I feel there is a problem with your connectivity or with the Github datacenter you are being routed to. That has not been my experience.
chinathrow 1 days ago [-]
git clone works sometimes, sometimes not.
1 days ago [-]
grishka 1 days ago [-]
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.
Why haven’t they asked an AI agent to fix all their bugs yet? /s
Ampersander 1 days ago [-]
Why does anyone even use Github anymore? Just generate a better forge with AI
refactor_master 1 days ago [-]
Prompting the wrong things is just a skill issue.
SlightGenius 24 hours ago [-]
[flagged]
fredsted 1 days ago [-]
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.
malikolivier 1 days ago [-]
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.
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.
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.
Github's status page is incredibly slow in comparison to the status page Github themselves used to have, which had several key metrics of various systems that would update in real time, and when they did have a (comparatively rare) outage, would usually have at least one metric going "yeah, something is wrong".
We have outages on our books that they never reported even after we ticketed them.
They cook the stats like an inner city police department.
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
Question 1: Is it github, or is it everyone:
Answer: https://downdetector.com/
(If everyone's having issues, then stop. Otherwise, continue below...)
---
Question 2: Is it github?
Answer 2: https://www.githubstatus.com/
Question 3: Why are you lying to me, is it github or not?
Answer 3: https://mrshu.github.io/github-statuses/
(If github is not having issues, then check your local environment. Otherwise, continue...)
---
Question 4: Why is it always github, surely they're not that bad right?
Answer: https://www.dayswithoutgithubincident.com/
(Perhaps its time to consider an alternative to github, or at least a mirror)
ECR just seems to work really well for most people and IAM is nice compared to Github Apps + rate limits
> 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.
Disclaimer: I am building a code forge myself
I am requesting to merge my changes into the main branch.
Similarly: Why are the Gitlab people so happy to merge? Where is my "Rebase Request", "Squash Request", or "Cherry-pick Request"?
Once all is good, push into remote HEAD and GithHub should auto-close.
Though, larger project tend to leave the final upstream merge to GitHub itself. Better access control and it’s easier to serialize merges through a single queue for very active projects.
related tidbit: in git, "pull" is basically shorthand for "fetch + merge".
You're literally replacing a well designed resilient system with a single point of failure run by a different company...
Wait, Jenkins?
Gitea Enterprise would be worth looking at.
https://about.gitea.com/products/gitea-enterprise/
I have it for all my stuff (dozens of repos and hundreds of PRs/builds per week) and it's only once in the last year that I've exceeded the free resource levels. I don't know if it's just extra capacity or they're burning VC dollars in the hopes of inspiring posts like this, but either way I feel like I'm taking advantage of them at this point.
If you're looking for a publicly-accessible Forge SaaS for your private repos and are willing to pay for it, you are almost certainly a company developing proprietary software.
https://woodpecker-ci.org/docs/usage/services
https://gitsocial.org/
It's a great service though
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.
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.
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.
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.
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 :)
I joke, the QoL is really nice
> git@github.com: Permission denied (publickey). fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.
git -c credential.helper= -c 'credential.helper=!gh auth git-credential' pull https://github.com/myorg/my-repo.git
git config --global url."https://github.com/".insteadOf git@github.com:
so it pushes / pulls using HTTPS
when things are back to normal run:
git config --global --unset url."https://github.com/".insteadOf
Wait…
https://rubyonrails.org/2026/11/4/Rails-8.0.5.2-and-8.1.4.1-...
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 us not being the source of the AI DDoS that GitHub has happily been welcoming.
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.
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.
new incident with actions now - https://www.githubstatus.com/incidents/h02n9572mx9y.
What were the 60'000 people exiting Microsoft doing if not improving Github?
Perhaps these types of posts should just be pinned at this point.
I can live with the occasional outage but this is a constant problem.
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.
https://www.githubstatus.com/incidents/xr3myzj7ms51
https://www.githubstatus.com/incidents/h02n9572mx9y
Get your act together, clowns.
It's up to you if you want more of this instability. Perhaps you should consider a self-hosted alternative.
[0] https://news.ycombinator.com/item?id=50307843
Some of our customers unexpectedly started using the service we're running as a file-cache around GitHub to mitigate GitHub outages.
We wrote about this use case in our blog: https://www.stablebuild.com/blog/protect-your-builds-from-gi...