Comment by grogenaut
18 hours ago
I may have my timelines wrong but I don't remember github being rock solid 5 years ago. I remember multiple outages keeping us from pulling code for go packages that were not using an enterprise dependency cache and killing multiple days of work a year for those systems. It's what I used as a forcing function to move people TO an enterprise dependency cache, and to find the few scofflaws running work code off of github.com versus enterprise.
You're right. I was misremembering this graph:
https://damrnelson.github.io/github-historical-uptime/
Actually to me the answer is Ms made them get more accurate in their graph. It was definitely not Rick solid in 2015-2018
https://techcrunch.com/2017/07/31/github-goes-down-and-takes...
Another line on that graph should probably be "January 7, 2019: GitHub offers unlimited free private repos". I can't imagine that helps with service stability.
That is a pretty wild graph
There is no way Github had 100% uptime prior to the MS acquisition. Nobody has 100% uptime 100% of the time. They must have changed how they were measuring uptime.
Can you explain more of what you mean by "wild" here?
I never worked on any SaaS that had such high uptime. It seems pretty good to me. In 10 years, it was always better than 99.5% uptime. That seems impressive to me for a huge, complex SaaS like GitHub.
2 replies →
Feels like a pretty wildly misleading graph. What do they say about lies, damned lies and statistics?
This graph is literally designed to abuse correlation =/= causation by attaching the arbitrary label "microsoft acquires github" so that the reader will apply causation to the uptime.
Now let's overlay ontop of the uptime graph a few lines of: # of monthly active users, # of monthly commits, size of PRs, action minutes per PR (whatever demonstrates scaling)
Something tells me that the uptime issues follow scale more than they do ownership... but that's not the narrative that this chart was designed for...
2 replies →