Additionally any potentially disruptive work like upgrades etc can be scheduled outside of business hours so that they won't impact users
Something tells me that if you can schedule upgrades "outside of business hours", your scale is small (because in a global company, it's always "business hours" somewhere), which makes the cost argument even more prominent.
And any large business will already be doing Backups, DR etc for their existing systems.
Any? Are you sure?
If you work in a large business that needs git but doesn't have backups and has no disaster recovery plan at all you're going to have much bigger things to worry about than a git repo being offline.
Gonna call BS on that.
It can achieve better uptime, if you ignore the downtime for upgrades, the downtime for configuration errors, the downtime when the disk fills up...
Besides the last one, the others you can schedule when developers are not actually working on something, or give a headsup so developers can be prepared in case of errors.
In the case of GitHub, Microsoft deploys changes whenever they want, whenever you want it or not.
That's because GitHub is used by millions of people every day all over the world. Business hours for them are around the clock. No matter when they update, if it breaks something, many people will hear about it regardless of when the break was deployed.
Btw, you cannot compare a scheduled maintenance window with an unplanned downtime ... maybe in the middle of an important deployment.
So 10 minutes a month for upgrades, zero time for the rest because you are managing it just fine.
Not add new features every week? Seriously, you cannot tell me that you cannot run a minimal version of a git repo service much more stable than that. I blame the need for new shiny stuff.
Ya'll make me laugh. Don't add any features and "This thing is dead, nothing new in years, find an alternative" But a company actively adds new features their customers are asking for and you're upset that they're adding new features.
Pick a lane.
I know the comments of these posts before I even open them. HN is an echo chamber of predictability.
I'd be interested to see if there is any correlation there.
Although I guess the benefit is that the CTO gets a psychological lift of looking over Jeremy from IT's shoulder when he tries to fix the issue rather than being at the mercy of some engineers which the company can't fire.
Some wiz-bang new graduates calling themselves Engineers probably haven't a clue - sure, but for everyone else, you probably still have folks employed that did just that on a professional level.
It's not hard - and often it's less expensive. Particularly for a turn-key paid product like Github Enterprise or GitLab.
I've been running self-hosted software, and GitLab in particularly, for over a decade at various jobs.
It almost never goes down. It fact, its up way way way more often that GitHub!
I set aside time today to go through my notifications and I can’t because of this. Notifications are trickier to decentralise but still, ugh.
All it takes is more people using it, and people here on HN are more suitable than others to start playing around and build their projects with it.
If todays developers were tasked to build the World Wide Web again, we would all log into some oAuth portal.
For comparison, check Fossil - https://www.fossil-scm.org/
With that in mind, your comment is similar to complaining about Jira being down, or Jenkins... they are different products.
Github was created to literally bring central server to a decentralized system. Yes, when that central server goes down, that's a problem for its users. It has nothing to do with Git.
You can, if you'd like, send Git patches in emails, or via snail mail, and you won't be influenced by any outages outside of individuals' laptops (which will affect only those individuals). Also, good luck managing your 250 microservices that way.
all I could say was, uhhhh github is a single point of failure. Unless you're mailing diffs around like Linus (which nobody I knew did), it's 6 of one, half-dozen of the other.
there are lots of great things about git and especially git over e.g. svn (especially merges) but I never bought the decentralization argument the way it was spearheading the conversation back then.
I would say the decentralised features of git work for me. And they are no overblown.
This is like blaming Bitcoin for your exchange collapsing. :p
The point has been missed hardcore.
That being said, Fossil has what you want. Are you willing to switch?
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
remote: fatal error in commit_refs
! [remote rejected] main -> main (failure)
error: failed to push some refs to '$REPO'
I think we should applaud this when it actually happens. Far too many services are terrible for this. While I'd rather the service not be down, it makes me feel a bit better if they don't lie about it.
If one gets dopamine/validation/click thru revenue from others consuming/clicking on media one shared,and further feel "unfairly gamed" when someone else gets that payout, it's a short time before one starts subconsciously appealing to the human lizard brain and sensationalizing media.
There's no way it's DNS
It was DNS
Everything resolved at the same time. DNS?
At this point maybe it is time to self-host rather than to continue to tolerate this since it's guaranteed to goes down every month. 
Even open-source projects like RedoxOS, GNOME, KDE, ReactOS, etc are doing just fine without worrying about GitHub's unreliability as predicted years ago on not centralizing everything to GitHub. 
Not a single one of these outages has caused me enough pain to even consider moving to another hosted provider let alone self-hosting and the burden that goes into managing all that stuff.
Can we stop with this whole "omg a major platform that gets used by millions of people a day can't guarantee 100% uptime, we need to all manage our own infra!!" mentality?
Seriously I've been in GitHub all morning and decided to take a break and read HN and I was JUST learning about this now... It was resolved before I seen this thread too.
(It's always dns.)
nc bofh.jeffballard.us 666 # I am surprised this is still working given its age; the CGI version at https://pages.cs.wisc.edu/~ballard/bofh/ doesn't work anymore (but the page is still up)