An important thing to consider is how much of their uptime without incidents is not the normal working hours. Their incident-free uptime on 9-5 EST, Mon-Fri, is probably like 60%.
what's normal working hours? very US centric comment IMO. Europe, India, China, Latam etc. don't fall into your 9-5 EST normal working hour bucket.
GitHub Outage Tracker: Is GitHub Cooked?
31–40 of 195 posts
Re: GitHub Outage Tracker: Is GitHub Cooked?
#32I think we need to have a little more sympathy for GitHub. You could justify the jabs when we could all blame any outage on the migration to Azure, but then they shared numbers around the scale they're dealing with now that everyone is constantly building and pushing with AI. I think it's commendable that they're not limiting access to the site or (intentionally) throttling newcomers. Yes, they need to get this figur…
Sympathy? It's a Microsoft company that is being ran with a consistency of a startup in early seed rounds. Their downtime is abhorrent and unacceptable as far as enterprise goes. Their engineers look like absolute amateurs allowing for such low class work it results in their customers experiencing industry leading downtime.
Re: GitHub Outage Tracker: Is GitHub Cooked?
#33> "GitHub has had 1125 incidents since February 2016, implying a monthly incident rate of 24" 1125 incidents / 126 months ≈ 8.9 incidents per month, not 24 still terrible, but why such an obvious error in the first sentence...
Re: GitHub Outage Tracker: Is GitHub Cooked?
#34Re: GitHub Outage Tracker: Is GitHub Cooked?
#35> "GitHub has had 1125 incidents since February 2016, implying a monthly incident rate of 24" 1125 incidents / 126 months ≈ 8.9 incidents per month, not 24 still terrible, but why such an obvious error in the first sentence...
GitHub has had 1125 incidents since March 2016. Over the last 3 months, they've averaged 24 incidents per month
edit: although they also have 1.2 days of downtime (in a day) for their 'worst days' of downtime table, which suggests some auto number crunching is not working as expected.Re: GitHub Outage Tracker: Is GitHub Cooked?
#36Earlier quoted context omitted.
We have a business relationship so no we shouldn’t have any sympathy. They sell a service and they’re failing to provide it.
Why? If we have sympathy for Apple then we can have sympathy for Microsoft ...
Re: GitHub Outage Tracker: Is GitHub Cooked?
#37Earlier quoted context omitted.
We have a business relationship so no we shouldn’t have any sympathy. They sell a service and they’re failing to provide it.
Why? If we have sympathy for Apple then we can have sympathy for Microsoft ...
Re: GitHub Outage Tracker: Is GitHub Cooked?
#38Re: GitHub Outage Tracker: Is GitHub Cooked?
#39> "GitHub has had 1125 incidents since February 2016, implying a monthly incident rate of 24" 1125 incidents / 126 months ≈ 8.9 incidents per month, not 24 still terrible, but why such an obvious error in the first sentence...
Looks like they fixed it already
Re: GitHub Outage Tracker: Is GitHub Cooked?
#40Earlier quoted context omitted.
> I think it's commendable that they're not limiting access to the site or (intentionally) throttling newcomers. I don't think this is commendable at all. I give GitHub a lot of money and I'm tired of it being wasted with downtime.
It's a shame that the GitHub org that we use at my job that we pay a lot of money for gets affected the same way my personal nonsense does. I don't know the architecture or any of that, but I feel like there could be (and it's not like they would've really known this until the last year or two with the massive spike) separate infrastructure for paid users/orgs vs free the same way they make the distinction with enter…
Of course it is not free of all management but for our use case it is working.
There are hiccups with the CI runners from time time but nothing major and we have another machine in another rack that serves as a backup which can be brought up ~I know companies have long since tossed their expertise for hosting their own stuff in favour of SaaS but at some point its hard to beat the up time of a single machine.