7 ms·

99.9% uptime for the last month [1] doesn't qualify as "a lot of outages" in my opinion. [1]: https://status.github.com/graphs/past_month https://status.github

99.9% uptime for the last month [1] doesn't qualify as "a lot of outages" in my opinion. [1]: https://status.github.com/graphs/past_month https://status.github.com/graphs/past_month

riquito 11y ago
I find 43 minutes of outage in one month for a well paid service a bit much
BillinghamJ 11y ago
They seem to be a significant target for DDOS attacks, which seem to have been quite frequent. That uptime measure is for the application server, which I suspect does not include GitHub Pages which is hosted separately on static content servers. Lastly, 99.9% uptime over a month means 43 minutes of downtime. To me, that sounds like quite a lot.
- darrenkopp 11y ago
  The likelyhood that you have downtime at the exact same time GitHub does is fairly low though.
joantune 11y ago
AFAIK they have sharded their pages and repositories in a way that if one gets DDoS, usually it's only that piece that gets downtime (I know this because there was a problem with the Chinese government and a Github repo, that got constantly attacked, but that was the only repo suffering). Ofcourse, if one does a sharding, it's bound not to be repo by repo, so there might be adjacent ones suffering. But I use GH everyday, can't remember a time when it was offline.
- joantune 11y ago
  Here is the confirmation of such a mechanism (they simply rate limit certain repos): "All of these factors combine to make CocoaPods/Specs one of the top five most resource-costly repositories that we host on all of GitHub.com. And that is why it is rate-limited; otherwise it would consume even more resources and cause service interruptions for other GitHub users. The symptoms of the rate limiting for you and your users are that your repository accesses (clones, fetches, pushes) have to wait in a queue on our end, sometimes for a long time, before being processed. This causes fetches/clones to take much longer than they would otherwise, and might cause timeouts at your end. Moreover, if the load on our servers becomes too overwhelming, a fraction of the accesses might be rejected altogether." From: https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomment-193772935 https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...

99.9% uptime for the last month [1] doesn't qualify as "a lot of outages" in my opinion. [1]: https://status.github.com/graphs/past_month https://status.github.com/graphs/past_month

riquito 11y ago

I find 43 minutes of outage in one month for a well paid service a bit much

BillinghamJ 11y ago

They seem to be a significant target for DDOS attacks, which seem to have been quite frequent. That uptime measure is for the application server, which I suspect does not include GitHub Pages which is hosted separately on static content servers. Lastly, 99.9% uptime over a month means 43 minutes of downtime. To me, that sounds like quite a lot.

darrenkopp 11y ago
The likelyhood that you have downtime at the exact same time GitHub does is fairly low though.

joantune 11y ago

AFAIK they have sharded their pages and repositories in a way that if one gets DDoS, usually it's only that piece that gets downtime (I know this because there was a problem with the Chinese government and a Github repo, that got constantly attacked, but that was the only repo suffering). Ofcourse, if one does a sharding, it's bound not to be repo by repo, so there might be adjacent ones suffering. But I use GH everyday, can't remember a time when it was offline.

joantune 11y ago
Here is the confirmation of such a mechanism (they simply rate limit certain repos): "All of these factors combine to make CocoaPods/Specs one of the top five most resource-costly repositories that we host on all of GitHub.com. And that is why it is rate-limited; otherwise it would consume even more resources and cause service interruptions for other GitHub users. The symptoms of the rate limiting for you and your users are that your repository accesses (clones, fetches, pushes) have to wait in a queue on our end, sometimes for a long time, before being processed. This causes fetches/clones to take much longer than they would otherwise, and might cause timeouts at your end. Moreover, if the load on our servers becomes too overwhelming, a fraction of the accesses might be rejected altogether." From: https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomment-193772935 https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...