Azure's going to suffocate github. I'm curious to see what's next. Will self-hosting the code repository come back in vogue or will another social-coding platform take off?
Things can go wrong, but really, its been a lot and we're normalizing that to an unhealthy degree...
I wonder if it was down that much, if users would get credits the way we pay when we use the services - its kind of ridiculous for a critical service to be down that much and all we do is "ah okay, its just github". Like, as if that was normal to be down that much...
I don't think it's been "normalized". Github uptime is literally a joke in the tech community. They have first mover advantage and a behemoth behind them so they're not going away, but everyone knows how shit it's uptime is. It takes time for organizations to move away from services like this but I would bet anything that many are starting to try to move away, as well as new companies knowing they shouldn't use the service.
I'm told that GitHub has asserted to us that moving to this model means we would not be exposed to github.com outages. It's not at feature parity with github.com though.
We're currently on "GitHub Enterprise Cloud" on github.com and are affected by this outage (even though we use self-hosted runners!), but we're not on "GitHub Enterprise Cloud with data residency" on *.ghe.com, which I understand is/may not be affected by this outage?
“GitHub Enterprise Cloud with data residency” is hosted on separate infrastructure and dedicated subdomains under *.ghe.com. It’s been around since November 2024z
It’s not the same thing as GitHub Enterprise Cloud hosted on the shared global network on github.com.
Just to be clear, I am on Github Enterprise, and am also experiencing this disruption both privately and publicly on every org and project I have access to.
That's what I don't understand. They could mitigate their name so much if they just split free/paid/enterprise. It's already shown that enterprise is much more estable and is largely unaffected from service disruptions. Why don't they go one more layer? For sure it's worth the extra complexity.
There is no such thing as "just split" there is 20+ years of legacy decisions and even if the split is relatively clean it is still probably 1 years work for 200 people for maybe a marginal improvement.
The real money is going to go towards, "make this all more reliable".
Depending on the cause of the current issues, that move would likely cause more harm to paid services than good.
Their last postmortem made clear that their challenges are operational. Scale puts pressure on operation, but it's not what blocks them from keeping up.
Doubling the operation doubles the operational challenges.
It would probably be better to run projects with extremely high commit/merge frequency on a separate "slop infrastructure", basically like MMOs move cheaters to their own servers ;)
If the problem is scalability, just rate limit git commands on free accounts already. Nobody realistically need to push multiple times per minute, and that alone is bound to trickle down to anything that triggers on commits and pushes.
> Update - primary failover briefly improved performance but did not fully mitigate, we've throttled inbound traffic and are investigating upstream Vitess issues
>Update - primary failover briefly improved performance but did not fully mitigate, we've throttled inbound traffic and are investigating upstream Vitess issues
And now they're blaming their upstream vendor! Embarrassing stuff to be writing on a public page.
Vitess is a distributed mysql database. Github could very well be managing it entirely on their own. I have only seen people managing their own vitess, its entirely open source afaik.
I spent a bunch of time during the outage last week setting up forgejo and some custom action runners. At the time, I was worried I was wasting time and getting distracted from my real work...alas, I guess not. Gonna finish up that work and complete the move today.
> We've identified an issue with a database primary and are failing over to a replica immediately
This is why it's hard to take GitHub seriously. How can a single database cause an outage for everyone? This is amateur stuff. Have they no sharding or partitioning internally? Paying customers should not be impacted in the same way as free ones are.
RDBMS replication and failover is way more difficult and manual than anyone would like. You can't just set up two postgres, tell them they're clustered and have it basically work; at a minimum you have to design the client to somehow know which one is currently the master, or use some sort of proxy (which becomes its own SPOF).
RDBMS integrity basically requires that one master server is responsible for the whole data set and other servers may replicate from it. And it usually doesn't wait for a quorum of replicas, just for one, because the design is to recover from a hardware failure, not a network partition, although that could be fixed at the cost of increased latency.
> primary failover briefly improved performance but did not fully mitigate, we've throttled inbound traffic and are investigating upstream Vitess issues
Did you not read it? Just because there's a database primary doesn't mean there is 1 primary database. There's likely man redundancies and they have issue with how they're allocating traffic to them which is in turn causing an issue with how much traffic redundancies are receiving.
Another outage, this time with GitHub Actions. Last time that happened was 5 days ago [0] and another outage happened on the postmortem announcement as well. [1]
While GitHub is imploding itself, maybe you should think about self-hosting.
Notice odd behavior on GitHub. Get gaslit by a green status page. Notice more odd behavior on GitHub. Think it must be me this time. See unusual action queuing. Ah, an incident on the status page. Go for a walk and check HN on my phone. The AI SDLC.
I noticed earlier this week that my URL bar now pre-fills githubstatus.com instead of github.com when I type "gith"
A browser extension to indicate githubstatus being yellow/red:
https://chromewebstore.google.com/detail/is-github-down/lcfo...
A VSCode extension:
https://marketplace.visualstudio.com/items?itemName=RuslanRy...
Firefox:
https://github.com/matagus/github-status-checker
Caveat: https://news.ycombinator.com/item?id=49450924
(disclaimer: none of these are recommended by me to use - merely sharing to build on for this discussion)
For me this started happening when I type "stat" too.
Which surprised me because of the many hundreds of services I rely on regularly that also have status pages.
Good lord, hundreds?!
Uptime reliability is nkt additive, it's multiplicative, sometimes even logarithmic.
Downtime of 99% and 99% is 98.1%. I hope almost all those services are non-prod related.
Fun read about Azure and having 173 agents running a node: https://isolveproblems.substack.com/p/how-microsoft-vaporize...
Probably just a coincidence that Github started to have issues after beginning their move to Azure at the end of last year.
Azure's going to suffocate github. I'm curious to see what's next. Will self-hosting the code repository come back in vogue or will another social-coding platform take off?
My small org has definitely had internal discussions around self-hosting gitlab. We'll see what happens.
One of my favorite articles posted here for this year, it's a great read and really gives you an idea of just how dysfunctional azure is.
Things can go wrong, but really, its been a lot and we're normalizing that to an unhealthy degree...
I wonder if it was down that much, if users would get credits the way we pay when we use the services - its kind of ridiculous for a critical service to be down that much and all we do is "ah okay, its just github". Like, as if that was normal to be down that much...
I think the authors of SMTP had a healthy attitude to server uptimes:
https://datatracker.ietf.org/doc/html/rfc5321#section-4.5.4....I don't think it's been "normalized". Github uptime is literally a joke in the tech community. They have first mover advantage and a behemoth behind them so they're not going away, but everyone knows how shit it's uptime is. It takes time for organizations to move away from services like this but I would bet anything that many are starting to try to move away, as well as new companies knowing they shouldn't use the service.
GitHub needs to completely bifurcate their enterprise/paid services from their free services at the infra level.
They have that-ish as an option: https://docs.github.com/en/enterprise-cloud@latest/admin/dat...
I'm told that GitHub has asserted to us that moving to this model means we would not be exposed to github.com outages. It's not at feature parity with github.com though.
Thanks, this option is good to know.
We're currently on "GitHub Enterprise Cloud" on github.com and are affected by this outage (even though we use self-hosted runners!), but we're not on "GitHub Enterprise Cloud with data residency" on *.ghe.com, which I understand is/may not be affected by this outage?
According to their status pages (e.g. https://eu.githubstatus.com/, https://us.githubstatus.com/), their Enterprise Cloud uptime for Actions is significantly higher.
“GitHub Enterprise Cloud with data residency” is hosted on separate infrastructure and dedicated subdomains under *.ghe.com. It’s been around since November 2024z
It’s not the same thing as GitHub Enterprise Cloud hosted on the shared global network on github.com.
https://docs.github.com/en/enterprise-cloud@latest/admin/dat...
That is a different and later product with a confusingly similar name.
Just to be clear, I am on Github Enterprise, and am also experiencing this disruption both privately and publicly on every org and project I have access to.
That's what Azure DevOps is supposed to do, but for some reason GitHub has a redundant enterprise division.
That's what I don't understand. They could mitigate their name so much if they just split free/paid/enterprise. It's already shown that enterprise is much more estable and is largely unaffected from service disruptions. Why don't they go one more layer? For sure it's worth the extra complexity.
There is no such thing as "just split" there is 20+ years of legacy decisions and even if the split is relatively clean it is still probably 1 years work for 200 people for maybe a marginal improvement.
The real money is going to go towards, "make this all more reliable".
Depending on the cause of the current issues, that move would likely cause more harm to paid services than good.
Their last postmortem made clear that their challenges are operational. Scale puts pressure on operation, but it's not what blocks them from keeping up.
Doubling the operation doubles the operational challenges.
It would probably be better to run projects with extremely high commit/merge frequency on a separate "slop infrastructure", basically like MMOs move cheaters to their own servers ;)
surely if they did that everybody would complain how github "lost its touch with open source since they now prioritize paid services"
enterprise is mostly separate, is it not? uptimes are significantly more reasonable on the enterprise status pages
We are in GHEC right now and GitHub Actions is not working. It's been down every time githubstatus.com says it's down.
Same for us, I'm not even sure what product that other "Enterprise" status page refers to..
I should make a business selling git hosting. Apparently it's really easy because it doesn't have to actually work.
Honestly?
If the problem is scalability, just rate limit git commands on free accounts already. Nobody realistically need to push multiple times per minute, and that alone is bound to trickle down to anything that triggers on commits and pushes.
GitHub Actions upkeep is down to one 9. I miss the days big tech aimed for four or five 9s of reliability :(
Must be a day ending in Y
At this point, maybe it'd be more appropriate for people to post about github to HN when githubs actually working.
https://www.dayswithoutgithubincident.com/
Certificate expired over 100 days ago
Where do you see that?
Common Name (CN) www.dayswithoutgithubincident.com
Organization (O) <Not Part Of Certificate>
Common Name (CN) YR1
Organization (O) Let's Encrypt
Issued On Monday, August 10, 2026 at 10:01:51 AM
Expires On Sunday, November 8, 2026 at 9:01:50 AM
also seeing an expired cert:
This matches what I'm seeing.
> Update - We've identified an issue with a database primary and are failing over to a replica immediately
Seems like a weird thing to post on a status page. Shouldn't this have happened automatically and therefore precluded the need to inform users of it?
> Update - primary failover briefly improved performance but did not fully mitigate, we've throttled inbound traffic and are investigating upstream Vitess issues
>Update - primary failover briefly improved performance but did not fully mitigate, we've throttled inbound traffic and are investigating upstream Vitess issues
And now they're blaming their upstream vendor! Embarrassing stuff to be writing on a public page.
Vitess is a distributed mysql database. Github could very well be managing it entirely on their own. I have only seen people managing their own vitess, its entirely open source afaik.
I read that as an upstream service they own, but I agree the wording a bit weird.
Why is that a problem if it _is_ an upstream vendor problem? (assuming it is)
I spent a bunch of time during the outage last week setting up forgejo and some custom action runners. At the time, I was worried I was wasting time and getting distracted from my real work...alas, I guess not. Gonna finish up that work and complete the move today.
Same time next week?
So a normal Wednesday
The joke was a good one the first, second, or third time. It's not even funny anymore...
Was wondering why all my Actions just stopped running
Ah so that's why I got a random "github-merge-queue Bot removed this pull request from the merge queue due to no response for status checks"
I have switched off from github to my own server besides two websites that depend on gitbub integration to deploy to clpudfare pages
must feel bad that at this point every dev checks github status before going to work like it was the weather app.
We can't keep living like this.
Apparently we can because a lot (most?) of us are still using GitHub even after all their outages recently.
Except nobody moves to a privately hosted "gitweb"...
> We've identified an issue with a database primary and are failing over to a replica immediately
This is why it's hard to take GitHub seriously. How can a single database cause an outage for everyone? This is amateur stuff. Have they no sharding or partitioning internally? Paying customers should not be impacted in the same way as free ones are.
2.9B commits per month; 100M action runs per day; I think they probably have some sharding.
I wonder what is this database, and why it is hard to fall-over automatically.
RDBMS replication and failover is way more difficult and manual than anyone would like. You can't just set up two postgres, tell them they're clustered and have it basically work; at a minimum you have to design the client to somehow know which one is currently the master, or use some sort of proxy (which becomes its own SPOF).
RDBMS integrity basically requires that one master server is responsible for the whole data set and other servers may replicate from it. And it usually doesn't wait for a quorum of replicas, just for one, because the design is to recover from a hardware failure, not a network partition, although that could be fixed at the cost of increased latency.
Thanks! I didn't get the chance to manage RDBMs but that's good to know.
Possibly vitess from the latest update:
> primary failover briefly improved performance but did not fully mitigate, we've throttled inbound traffic and are investigating upstream Vitess issues
Thanks!
Did you not read it? Just because there's a database primary doesn't mean there is 1 primary database. There's likely man redundancies and they have issue with how they're allocating traffic to them which is in turn causing an issue with how much traffic redundancies are receiving.
Why shouldn't it? Most companies run on a single database server. If they can immediately fail over to a replica, that's doing it right.
Maybe you expect that part of GitHub to have a scale where a single database can't handle it, but evidently that isn't true.
We can criticise them for not splitting up free and paid customers but again, most companies don't do that.
Another outage, this time with GitHub Actions. Last time that happened was 5 days ago [0] and another outage happened on the postmortem announcement as well. [1]
While GitHub is imploding itself, maybe you should think about self-hosting.
[0] https://news.ycombinator.com/item?id=49379172
[1] https://news.ycombinator.com/item?id=49379225
Oh thank god my pink unicorn site is back online, its had great uptime lately so thats nice.
Cursor had better not miss this opportunity.
Notice odd behavior on GitHub. Get gaslit by a green status page. Notice more odd behavior on GitHub. Think it must be me this time. See unusual action queuing. Ah, an incident on the status page. Go for a walk and check HN on my phone. The AI SDLC.
The status page is the last one to get the update. Reddit, HN, X, company chat are all always reporting it sooner.
So what’s stopping you (or your org) from leaving GitHub?
Must be a weekday
Can't even run self hosted github actions lol
https://cursor.com/origin