4 ms·

Every time one of these vibe coded meme sites gets posted there’re endless comments about how it’s not actually because of load, the GitHub team is shit, their

Every time one of these vibe coded meme sites gets posted there’re endless comments about how it’s not actually because of load, the GitHub team is shit, their tech stack is shit, Microsoft is shit, Azure is shit, etc. Just compare the GitHub status page for public GitHub vs the enterprise cloud pages. Enterprise has much better numbers and I’ve personally can’t remember the last time there was an outage that prevented me from doing work. If the problems didn’t revolve around load, I’d expect to see the same uptime problems reflected on the enterprise offering.

Anoian 5mo ago
Why cannot both sides be right? Meaning that the load is crazy high but also that the tech stack and everything else is bad?
semiquaver 5mo ago
What do you mean by enterprise cloud? The default GitHub enterprise cloud plan is hosted on the same infra as “public github.” Do you have a link to what you mean?
- taspeotis 5mo ago
  Bottom of the status page links to the Enterprise regions? > Check GitHub Enterprise Cloud status by region: > - Australia: au.githubstatus.com > - EU: eu.githubstatus.com > - Japan: jp.githubstatus.com > - US: us.githubstatus.com
- lenerdenator 5mo ago
  Interested in this difference as well. It'd make sense if there was a "you get what you pay for" attitude at MS re: public GitHub. It's not a good position for the free users, but, what else are you gonna do? Stand up your own? Retrain yourself on your SDLC in a new platform? They need a competitor.
  - chrisweekly 5mo ago
    GitLab
- EE84M3i 5mo ago
  It sounds like they're talking about "GitHub Enterprise Cloud with Data Residency." This is a separate product to the standard "GitHub Enterprise Cloud" (including Enterprise Managed Users) which runs on normal github.com infrastructure. If you have a Data Residency tenant, you access it through an endpoint like octocorp.ghe.com GitHub seems to try to use specific language here to avoid this confusion, because they are quite different products, but it seem to me they were named confusingly in the first place...
dijit 5mo ago
> the GitHub team is shit, their tech stack is shit 1) Criticism of being unable to achieve service is not a fault of the individual; it simply is a fault of the system. You can criticise the system, it's permissible. Especially if they have more resources than many countries and some of the best tech talent in the world on staff. 2) Their tech stack is shit, and they've gone on record for years defending it, quite arrogantly in some cases, as if nobody can possibly know anything unless they've done github (even if you've done things which scale, or someone comes in with an even larger scale, the people on HN will happily say "but it's not github" which is valid but not intellectually curious or open). Azure is terrible and it's being foisted on the team: even if they found some technical people to put at the top who are saying it'll be ok: it is a pretty cruel platform to use. I've personally had a few conversations about their choice of relational database which were handled pretty defensively, and I think we're all somewhat cognisant of their frontend rewrite. It's a waste of time to rewrite the UI and push AI tools when you can't even keep the site lit. I have nothing against the engineers- I don't know why people keep chiming in as if we're punching down at "lowly engineers" when the reality is that it's a management failure of the highest order. They're a billion-dollar company owned by a trillion-dollar one... it's very hard to "punch down" at this system: nobody is going after the engineer, we're punching the fact that the system that is a defacto monopoly due to network effects is putting new features or pleasing their owners over the core offering.. How is that an engineering failure? That's an active choice by management.
- linsomniac 5mo ago
  >not intellectually curious or open This checks out. I once was at a conference where they (Azure) had a giant booth. A fairly well known person in the community brings me over to talk to his manager who is working the booth. "We should hire him, he's really smart." Within a minute of talking to this manager he says "You're a Linux guy? We do Windows." and physically turns away from me, conversation over. You know, fair enough, was an easy way to find that it wasn't a good fit. But the lack of curiosity about "what do you bring to the table" was pretty stunning. Be curious. edit: Clarifying "they"
  - someguyiguess 5mo ago
sqircles 5mo ago
Odd, our Enterprise side has been jacking up for a few days now on PRs.
s_dev 5mo ago
It's common knowledge that the official status pages don't actually reflect downtime due to SLAs and the status page could be weaponised against them. So comparing them is useless. You rarely see "outages" even if that what happens in reality, in marketing speak it's referred to as 'degraded performance' i.e. the cheque is in the post, your data is in the tubes on it's way, it's just slow! A business oriented lie. Far more useful are the 'independent status pages' maintained by enthusiasts that are unaffiliated with whomever they are measuring.
- john_strinlai 5mo ago
  >Far more useful are the 'independent status pages' maintained by enthusiasts that are unaffiliated with whomever they are measuring. unless, like this one, they: - treat "some copilot chat models are failing" and "teams notifications app down" as a major outage, the same as git operations or actions failing... those are very obviously nowhere near the same operational impact and its dishonest to group them as the same - aggregate downtime so that there is greater than 1 day of possible downtime in a 24 hour period. if 3 services are down for the same 1pm-2pm time period, that is being counted as 3 hours of downtime despite a developer only being impacted for 1 hour. it would be cool to have an accurate status page. the only two options seem to be company-owned status pages (incentivized to under-state impact) and karma-hunter/meme status pages (incentivized to make as much red as possible for retweeting or whatever).
somehnguy 5mo ago
I think 2 things may be combined here. 'GitHub Enterprise Server' is hosted on your own resources, not their cloud. It makes sense that it wouldn't have the same downtime as their cloud, but that's hardly relevant. 'GitHub Enterprise Cloud' is their offering hosted on their own resources and what I suspect most enterprise customers use. It's what I at $extremelylargecompany use. It follows the same uptime/downtime as their public non-enterprise offering.
- voxic11 5mo ago
  No if you use GitHub Enterprise Cloud with data residency then you are on separate infrastructure. Here is the status page for the US enterprise cloud data residency https://us.githubstatus.com/posts/dashboard https://us.githubstatus.com/posts/dashboard (which funny enough is reporting an issue atm). You can tell if you are on the github enterprise with data residency because you will access github at a GHE.com domain rather than github.com. It definitely has better uptime than the public cloud but is not without its own issues.
  - everfrustrated 5mo ago
    It's still on Azure tho, so subject to Azures underlying problems....
whh 5mo ago
It's easy to forget GitHub isn't just one thing. It's a collection of many things. Some of us use a few things, some of us use lots of things. I, for one, am mostly happy with GitHub and have been for the last 18 years I've been using it. That said, GitHub Actions and Container Reg have been a bit... unreliable. This isn't to say all of GitHub is unreliable... just that these relatively new additions in GitHub's nearly 20 year history are a bit s** when it comes to uptime. I hope they can figure it out. :)
senko 5mo ago
> If the problems didn’t revolve around load GitHub is not a mom&pop operation. I expect the $3T company to handle the load, or at least place a prominent "only for hobby use" warning on top.
weird-eye-issue 5mo ago
I don't think people generally care what the exact reason is it's more about there being any downtime in the first place Also it's not a fair comparison because it's not necessarily the same code between the public and Enterprise...
JackSlateur 5mo ago
We are using the entreprise offering. We are seeing the problems.
michaelcampbell 5mo ago
> I’ve personally can’t remember the last time there was an outage that prevented me from doing work. You and I are in different domains. It's not daily, but I can't remember the last time I (in my company) went a week WITHOUT having to workaround some outage. Perhaps semantics, but I can "do work" through most of them, but that work isn't getting built or deployed in the same time frame it would have been had the outages not occurred. So "affected" is at least weekly for me.
- k_roy 5mo ago
  It's weekly for me. And that's just with PRs, not even builders. I can't imagine if I relied on their runners.
shevy-java 5mo ago
I don't see anything in your description that would imply that those who claim Microslop is performing at below-average-quality right now, can NOT be the underlying cause either. For instance, it may be that the problem is difficult to fix AND that Microslop is really really incompetent at solving this. That is one possibility at the least. > Just compare the GitHub status page for public GitHub vs the enterprise cloud pages. I am not sure why that would be an explanation either - it could be that enterprise gets more time and money, whereas the non-paying free-riders naturally get less. This would also make sense from a business point of view (to some extent, though if only enterprise would use github, it would lose its status as main source code hosting website on the planet quickly; others are already waiting to nibble away at GitHub, the more Microslop fails here).
jorl17 5mo ago
Ironically, I am in this very moment incapable of creating threads in PRs within my org because of a GH bug. It's on their status page, too. I can reply to an existing thread, just not create a new one. How does something like this even slip by?...and why has it been like this for an hour? EDIT: Oh, good, the issue should be solved in the next 3 or 4 hours. How lovely of them.
tiagod 5mo ago
I don't find your conclusion that obvious. They could also be deploying changes to their regular infrastructure before updating enterprise, shielding it from some mistakes.

Anoian 5mo ago

Why cannot both sides be right? Meaning that the load is crazy high but also that the tech stack and everything else is bad?

semiquaver 5mo ago

What do you mean by enterprise cloud? The default GitHub enterprise cloud plan is hosted on the same infra as “public github.” Do you have a link to what you mean?

taspeotis 5mo ago
Bottom of the status page links to the Enterprise regions? > Check GitHub Enterprise Cloud status by region: > - Australia: au.githubstatus.com > - EU: eu.githubstatus.com > - Japan: jp.githubstatus.com > - US: us.githubstatus.com
lenerdenator 5mo ago
Interested in this difference as well. It'd make sense if there was a "you get what you pay for" attitude at MS re: public GitHub. It's not a good position for the free users, but, what else are you gonna do? Stand up your own? Retrain yourself on your SDLC in a new platform? They need a competitor.
- chrisweekly 5mo ago
  GitLab
EE84M3i 5mo ago
It sounds like they're talking about "GitHub Enterprise Cloud with Data Residency." This is a separate product to the standard "GitHub Enterprise Cloud" (including Enterprise Managed Users) which runs on normal github.com infrastructure. If you have a Data Residency tenant, you access it through an endpoint like octocorp.ghe.com GitHub seems to try to use specific language here to avoid this confusion, because they are quite different products, but it seem to me they were named confusingly in the first place...

dijit 5mo ago

> the GitHub team is shit, their tech stack is shit 1) Criticism of being unable to achieve service is not a fault of the individual; it simply is a fault of the system. You can criticise the system, it's permissible. Especially if they have more resources than many countries and some of the best tech talent in the world on staff. 2) Their tech stack is shit, and they've gone on record for years defending it, quite arrogantly in some cases, as if nobody can possibly know anything unless they've done github (even if you've done things which scale, or someone comes in with an even larger scale, the people on HN will happily say "but it's not github" which is valid but not intellectually curious or open). Azure is terrible and it's being foisted on the team: even if they found some technical people to put at the top who are saying it'll be ok: it is a pretty cruel platform to use. I've personally had a few conversations about their choice of relational database which were handled pretty defensively, and I think we're all somewhat cognisant of their frontend rewrite. It's a waste of time to rewrite the UI and push AI tools when you can't even keep the site lit. I have nothing against the engineers- I don't know why people keep chiming in as if we're punching down at "lowly engineers" when the reality is that it's a management failure of the highest order. They're a billion-dollar company owned by a trillion-dollar one... it's very hard to "punch down" at this system: nobody is going after the engineer, we're punching the fact that the system that is a defacto monopoly due to network effects is putting new features or pleasing their owners over the core offering.. How is that an engineering failure? That's an active choice by management.

linsomniac 5mo ago
>not intellectually curious or open This checks out. I once was at a conference where they (Azure) had a giant booth. A fairly well known person in the community brings me over to talk to his manager who is working the booth. "We should hire him, he's really smart." Within a minute of talking to this manager he says "You're a Linux guy? We do Windows." and physically turns away from me, conversation over. You know, fair enough, was an easy way to find that it wasn't a good fit. But the lack of curiosity about "what do you bring to the table" was pretty stunning. Be curious. edit: Clarifying "they"
- someguyiguess 5mo ago

sqircles 5mo ago

Odd, our Enterprise side has been jacking up for a few days now on PRs.

s_dev 5mo ago

It's common knowledge that the official status pages don't actually reflect downtime due to SLAs and the status page could be weaponised against them. So comparing them is useless. You rarely see "outages" even if that what happens in reality, in marketing speak it's referred to as 'degraded performance' i.e. the cheque is in the post, your data is in the tubes on it's way, it's just slow! A business oriented lie. Far more useful are the 'independent status pages' maintained by enthusiasts that are unaffiliated with whomever they are measuring.

john_strinlai 5mo ago
>Far more useful are the 'independent status pages' maintained by enthusiasts that are unaffiliated with whomever they are measuring. unless, like this one, they: - treat "some copilot chat models are failing" and "teams notifications app down" as a major outage, the same as git operations or actions failing... those are very obviously nowhere near the same operational impact and its dishonest to group them as the same - aggregate downtime so that there is greater than 1 day of possible downtime in a 24 hour period. if 3 services are down for the same 1pm-2pm time period, that is being counted as 3 hours of downtime despite a developer only being impacted for 1 hour. it would be cool to have an accurate status page. the only two options seem to be company-owned status pages (incentivized to under-state impact) and karma-hunter/meme status pages (incentivized to make as much red as possible for retweeting or whatever).

somehnguy 5mo ago

I think 2 things may be combined here. 'GitHub Enterprise Server' is hosted on your own resources, not their cloud. It makes sense that it wouldn't have the same downtime as their cloud, but that's hardly relevant. 'GitHub Enterprise Cloud' is their offering hosted on their own resources and what I suspect most enterprise customers use. It's what I at $extremelylargecompany use. It follows the same uptime/downtime as their public non-enterprise offering.

voxic11 5mo ago
No if you use GitHub Enterprise Cloud with data residency then you are on separate infrastructure. Here is the status page for the US enterprise cloud data residency https://us.githubstatus.com/posts/dashboard https://us.githubstatus.com/posts/dashboard (which funny enough is reporting an issue atm). You can tell if you are on the github enterprise with data residency because you will access github at a GHE.com domain rather than github.com. It definitely has better uptime than the public cloud but is not without its own issues.
- everfrustrated 5mo ago
  It's still on Azure tho, so subject to Azures underlying problems....

whh 5mo ago

It's easy to forget GitHub isn't just one thing. It's a collection of many things. Some of us use a few things, some of us use lots of things. I, for one, am mostly happy with GitHub and have been for the last 18 years I've been using it. That said, GitHub Actions and Container Reg have been a bit... unreliable. This isn't to say all of GitHub is unreliable... just that these relatively new additions in GitHub's nearly 20 year history are a bit s** when it comes to uptime. I hope they can figure it out. :)

senko 5mo ago

> If the problems didn’t revolve around load GitHub is not a mom&pop operation. I expect the $3T company to handle the load, or at least place a prominent "only for hobby use" warning on top.

weird-eye-issue 5mo ago

I don't think people generally care what the exact reason is it's more about there being any downtime in the first place Also it's not a fair comparison because it's not necessarily the same code between the public and Enterprise...

JackSlateur 5mo ago

We are using the entreprise offering. We are seeing the problems.

michaelcampbell 5mo ago

> I’ve personally can’t remember the last time there was an outage that prevented me from doing work. You and I are in different domains. It's not daily, but I can't remember the last time I (in my company) went a week WITHOUT having to workaround some outage. Perhaps semantics, but I can "do work" through most of them, but that work isn't getting built or deployed in the same time frame it would have been had the outages not occurred. So "affected" is at least weekly for me.

k_roy 5mo ago
It's weekly for me. And that's just with PRs, not even builders. I can't imagine if I relied on their runners.

shevy-java 5mo ago

I don't see anything in your description that would imply that those who claim Microslop is performing at below-average-quality right now, can NOT be the underlying cause either. For instance, it may be that the problem is difficult to fix AND that Microslop is really really incompetent at solving this. That is one possibility at the least. > Just compare the GitHub status page for public GitHub vs the enterprise cloud pages. I am not sure why that would be an explanation either - it could be that enterprise gets more time and money, whereas the non-paying free-riders naturally get less. This would also make sense from a business point of view (to some extent, though if only enterprise would use github, it would lose its status as main source code hosting website on the planet quickly; others are already waiting to nibble away at GitHub, the more Microslop fails here).

jorl17 5mo ago

Ironically, I am in this very moment incapable of creating threads in PRs within my org because of a GH bug. It's on their status page, too. I can reply to an existing thread, just not create a new one. How does something like this even slip by?...and why has it been like this for an hour? EDIT: Oh, good, the issue should be solved in the next 3 or 4 hours. How lovely of them.

tiagod 5mo ago

I don't find your conclusion that obvious. They could also be deploying changes to their regular infrastructure before updating enterprise, shielding it from some mistakes.