官方Rackspace博客解释说：“在2009年12月18日下午3:37至4:12 CST之间，Rackspace经历了网络连接问题。”时间表并没有因为华盛顿邮报网站TechCrunch报告的时间戳说12:17 pm而引发争议。假设TechCrunch时间戳是太平洋时间，这意味着中断时间开始时间更长，或者甚至更早。
除了TechCrunch，其他一些服务和博客站点也受到Rackspace停机的影响，其中包括37个信号，Brizzly，Robert Scoble的博客，由Laughing Squid，Tumblr和Mashable主持的网站。
[进一步阅读：最佳NAS媒体流和备份框]
Rackspace博客描述了根本原因：一个用于对等和骨干连接的路由器位于数据中心之外的对等设备，处理大约20％Rackspace达拉斯流量的问题。“博客帖子继续解释路由器配置错误是对芝加哥和达拉斯设施之间的数据中心集成进行最终测试，并且在正常工作时间内不应影响运营。 “这些设施的网络整合计划在正常工作时间以外的每月维护时段进行，而今天的事件发生在最后的准备工作中。”
停机让许多Rackspace客户说：“嘿！谁关掉了云？ “
虽然影响流行和知名站点的数据中心中断对云计算普遍存在黑眼，但此次中断的影响范围相对较小。正如本博客所指出的：“Rackspace是小土豆，现在它是一个快速增长的土豆袋，但仍然很小，另一个问题是：Rackspace更关心托管而不是云。”
对于依赖Rackspace托管的客户他们的服务器 - 特别是Web服务器 - 看起来好像当Rackspace数据中心不可用时互联网出现故障似的。但是，像Amazon EC2和Microsoft Azure这样的云计算服务以及谷歌和亚马逊这样的互联网重要服务器根本没有受到Rackspace中断的影响。
错误发生，但Rackspace的客户有权质疑重复的中断和服务中断。至少有一名Rackspace客户也对与此类服务中断等网络问题的客户通知相关的问题感到不安。
客户的托管服务器受到Rackspace中断的影响，并从客户投诉中发现其网站已无法使用两次小时。客户在评论中称：“我们还向Rackspace支付额外费用，用于持续监控服务，如果我们的服务器随时无法访问，我们应该立即通过电子邮件或电话通知我。我非常不安地发现Rackspace实际上是SUPPRESSED这些通知由于一些奇怪的原因而被发送给他们的客户。“
该评论没有提供证据支持Rackspace故意拒绝通知的说法，而且我也没有从Rackspace得到任何确认或否认指控的反馈。如果事实证明这是真的，那么会损害Rackspace的可信度和客户服务声誉。
然而，底线是Rackspace确定问题的原因并相对较快地解决问题，并在博客上提供状态更新让消费者了解情况。即使短暂的停电对受其影响的人来说也是毁灭性的，但是他们会发生，而当他们这样做的时候，几乎是你想要他们处理的方式。
托尼布拉德利推文
@PCSecurityNews， ，可以在他的 Facebook页面 。