Nosso provedor de trânsito está inativo devido a uma falha grave de hardware. Não há tempo estimado para recuperação. Estamos ativando espelhos somente leitura dos sites de clientes padrão e empresariais em um local separado. (ref)
Seria possível obter uma entrada que possamos colocar em nossos arquivos hosts ou algum outro tipo de solução alternativa para nos conectarmos aos outros servidores para acesso a atualizações?
Olá @EricGT - se/quando mudarmos para outro local, todas as alterações serão tratadas automaticamente por nós. Você não precisa fazer nada.
(tecnicamente, alteraríamos os registros DNS dos sites afetados para apontar para o novo local)
Parece muito estranho que uma interrupção de serviço tão grande seja quase invisível aqui.
Apenas 1 thread (iniciado por um usuário, não por um administrador) com 2 postagens depois que alguns sites estão fora do ar há meio dia?
Por que não há comunicação?
O site está de volta em um servidor diferente e, embora eu não tenha feito uma verificação detalhada, está funcionando como esperado.
Obrigado. 
Olá @emyoulation
Temos uma página especial que você pode acompanhar para esse tipo de atualização de site hospedado:
Agradeço a página de Status. Mas ela não oferece um local para discutir quando a atualização de status carece de clareza.
Eu não tinha lidado com um “provedor de trânsito” e o termo não é bem pesquisado no Google. (Ele retorna mais resultados sobre pessoas se deslocando em transporte público do que sobre pacotes de internet se movendo.) E a “falha grave de hardware” pode ser qualquer coisa (desde seus geradores de backup ficando sem combustível durante uma queda de energia prolongada até o incêndio de seu prédio principal.) A comunicação inspirou ansiedade e incerteza em vez de aliviá-las.
No contexto da internet, um provedor de trânsito é alguém que transporta tráfego. Raramente, ou nunca, eles compartilham detalhes sobre as especificidades de uma falha. Na melhor das hipóteses, eles falarão sobre serviços degradados ou a gravidade relativa das interrupções.
Essas redes são tipicamente construídas com várias camadas de redundância, onde apenas falhas compostas podem levar a tempo de inatividade real. Existem alguns exemplos, como a CloudFlare, que ocasionalmente entram em detalhes minuciosos sobre interrupções, mas eles são a exceção e não a regra.
Bem, uma coisa boa é que essa experiência está nos fazendo reexaminar nosso método de comunicação com nossa comunidade quando há um problema.