> 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.

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.

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. :)

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.

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?

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

[dead]