51–60 of 81 posts
Thank god (Linus) that git is a distributed "protocol" letting you pull and push to any location on your file system or anywhere you can access over ssh.
Since last few months, GitHub has become very unreliable. For example, last month, they reported six official incidents in just one week. I've also noticed many shorter, non-official incidents (i.e. the ones where there is no active incident on their status page, but many API calls return a 500 error). I learned about this the hard way (we offer affordable GitHub Runners at Ubicloud, which gives us the opportunity to…
We’ve had to harden a bunch of automation to be more reliable in case of github going tits up, and while github is still currently the broker (as it’s where users get statuses / information from it made sense at the time to also have it handle broadcasts) we’re definitely planning on direct communication between services eventually.
Earlier quoted context omitted.
Status pages can never be trusted.
I always think this should be an incident in itself - why did our status page not reflect the reality of a degraded service? It's so common that they don't, and something user-driven like DownDetector is often more reliable
There was a conflict with marketing, market movement, sla contracts, and our image.
Classic Github for the past few years we are used to it / resilient now.
[flagged]
[0] > 'bloody annoying'
Earlier quoted context omitted.
Why would Ruby play a role in it? Azure definitely does though. (ex azure employee here )
GitHub itself is written in Ruby.
Since last few months, GitHub has become very unreliable. For example, last month, they reported six official incidents in just one week. I've also noticed many shorter, non-official incidents (i.e. the ones where there is no active incident on their status page, but many API calls return a 500 error). I learned about this the hard way (we offer affordable GitHub Runners at Ubicloud, which gives us the opportunity to…
The status page says it's been resolved 8 minutes ago (Apr 05, 2024 - 08:48 UTC): https://www.githubstatus.com/incidents/bnkkbj90yhz6 But it definitely still happens now (500s on refresh on PRs and GitHub actions) Edit: still ongoing Edit 2: still ongoing at Apr 05, 2024 - 08:56 UTC (keeping updated for the record since their status page cannot be trusted apparently) Edit 3: I see they have switched to a different (o…
Status pages can never be trusted.
My experience now tells me what we really need first is a solid alerting system, the status page can't be trusted. It's a PR tool (a useful one), not a sysadmin tool.
Earlier quoted context omitted.
I always think this should be an incident in itself - why did our status page not reflect the reality of a degraded service? It's so common that they don't, and something user-driven like DownDetector is often more reliable
I don't think an accurate and automated public status page is something any management would want. If it was accurate they wouldn't be able to lie to customers about the uptime. So I always suspect status pages are adjusted manually.
Earlier quoted context omitted.
[flagged]
> You make it sound like you are better at running a system at this scale with so many users. I don't care that the system scales to millions of people, my team is a dozen people, that's all I need something to do. And my downtime stats are far less that githubs, and they have never occurred during the working day. Nobody denies scaling is hard, they simply deny scaling is necessary.
git hosting is easy to scale (a.k.a. github classic). Dozens of technologies integrate into a frankenmonster (a.k.a. github modern) is hard to scale.
I like github projects, github co-pilot, CI/CD, etc. but I like stable github better.