I mean, internal CI and version control systems go down too. Like, if GitHub has substantially worse downtime than an whatever internal system one runs, fair enough.

Git's distributed, so downtime isn't usually a huge deal compared to a non-distributed version control system.

I think that the largest issue is actually that GitHub provides a centralized commit review system (and, to be fair, so are many internal systems) that one uses to review pull requests. Like, a CI run being deferred usually isn't a huge deal. Version control is probably distributed these days. But code review is something that you'd like to keep going.

If you do code review in email or something, it's distributed. You can keep working. If your email server goes down, it might prevent new messages from reaching other users, but all of the review requests you have can be worked on and any review you've already received can be read. But if people are using some centralized Web-based code review system, and that goes down, then that kinda halts a lot of stuff.

Same centralized problem for issue tracking.

EDIT: I've never used a distributed issue tracker, but apparently they are indeed out there:

https://github.com/git-bug/git-bug

EDIT2: A lot of issue trackers involve people attaching large files to issues, so there might be some fundamental scalability issues in that regard for distributed operation; might need to centralize that part. That being said, I'd rather temporarily lose access to just a large-file-hosting server than to that and all of the other issue data.

My company luckily didn't do this...

/BearLookawayMeme

Ours has been there for over a decade, It's not ideal, but moving it all is an undertaking. Over the years we've created alternative methods to work around the CI when it's down, Ideally we'd host our own