Apagão da Microsoft derruba Outlook, Teams e Copilot por mais de 12 horas

Doze horas de instabilidade, em cinco fusos diferentes

Na quinta-feira, 12 de novembro de 2026, o Outlook, o Teams e o Copilot começaram a apresentar erros de conexão em várias regiões do mundo. Mais de 12 horas depois, na manhã de sexta-feira, 13, a Microsoft ainda trabalhava para normalizar o serviço: por volta das 7h20 no horário de Brasília, o Teams já respondia, mas o Outlook e o Copilot continuavam fora do ar, segundo reportagem da Exame.

O Downdetector, plataforma que agrega relatos de falha, registrou cerca de 130 mil notificações sobre o Outlook por volta das 15h de quinta (Brasília). O volume caiu para 37 mil por volta das 20h, sinal de recuperação parcial, não de normalização.

Essa é a segunda interrupção relevante do Microsoft 365 neste ano, o que por si só já é um dado: não é um evento isolado para quem decide orçamento de continuidade de negócio.

A causa oficial: sobrecarga, não ataque

Segundo a Microsoft, o problema está em uma parte da infraestrutura enfrentando carga elevada em várias regiões simultaneamente, o que gerou erros de conectividade em cascata.

Determinamos que uma parte da infraestrutura está enfrentando uma carga elevada em várias regiões, o que possivelmente está contribuindo para os erros de conectividade.

Microsoft, em comunicado oficial

Para conter o problema, a empresa pausou novas implementações, redirecionou tráfego para longe dos servidores afetados e reiniciou equipamentos comprometidos, numa sequência clássica de mitigação de incidente: parar de piorar, desviar carga, restaurar capacidade aos poucos.

O detalhe técnico que mais interessa a quem arquiteta sistemas: a falha concentrou-se nos recursos que dependem do Exchange Online, o backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → de mensageria do Microsoft 365. Ferramentas que não passam por ali seguiram no ar. Não foi a nuvem da Microsoft inteira que caiu: foi um componente específico, mas um componente do qual e-mail, calendário, contatos e parte da lógica de notificação do Teams e do Copilot dependem.

Quem sentiu o apagão no bolso

A lista de afetados publicada pela Exame mostra o alcance do problema fora do eixo óbvio de usuário doméstico:

• Na Austrália, a agência de inteligência e a polícia federal operaram com sistemas de e-mail comprometidos.
• Nos Estados Unidos, a Câmara dos Representantes confirmou que suas equipes técnicas trabalhavam junto com a Microsoft.
• No Japão, o governo relatou impacto na própria infraestrutura de sistemas de informação.
• A OpenAI e a Anthropic relataram falha nos conectores que integram seus produtos a serviços da Microsoft.
• Na Índia, as companhias aéreas IndiGo e Akasa Air tiveram o atendimento por e-mail paralisado.
• Em Taiwan, corretoras e seguradoras tiveram operações de gestão de fundos travadas; uma empresa cancelou uma recompra de títulos já programada.
• Nos Estados Unidos, a fabricante de caminhões elétricos Workhorse Group adiou a divulgação do balanço do terceiro trimestre, de 12 para 16 de novembro, atribuindo o atraso diretamente à falha da Microsoft.

Esse último caso transforma o incidente de chatice operacional em evento de relações com investidores: uma empresa de capital aberto moveu a data de divulgação de resultado porque o provedor de nuvem caiu. É o tipo de linha que vai parar em ata de conselho.

O paralelo que a Austrália traçou com a CrowdStrike

A Microsoft nega qualquer indício de ataque. O ministro de Assuntos Internos e Segurança Cibernética↳Segurança171 conteúdosCibersegurança no Brasil: 6 passos para sair da estagnaçãoDevSecOps · jul 2025O papel do CISO para transformar a cibersegurança em uma alavanca de reputação para as empresasDevSecOps · mar 2024Itaipu Parquetec e Exército Brasileiro realizam exercício de cibersegurança em BrasíliaDev (Back & Front) · set 2025Ver tudo em DevSecOps → da Austrália, Tony Burke, foi além e comparou o episódio a um incidente que o setor de infraestrutura ainda trata como caso de estudo.

Eles acreditam que estão lidando, de certa forma, com algo parecido com o que vimos no caso da CrowdStrike, em que uma atualização deu errado. O impacto com que estão lidando está muito concentrado nos sistemas de e-mail.

Tony Burke, ministro de Assuntos Internos e Segurança Cibernética da Austrália

A referência não é gratuita. Em julho de 2024, uma atualização malformada de um sensor de segurança da CrowdStrike travou milhões de máquinas Windows em aeroportos, hospitais e bancos ao redor do mundo, numa falha que não teve nada de maliciosa e tudo de operacional. O padrão se repete aqui: não é invasão, é mudança de infraestrutura que deu errado em escala planetária, porque o provedor atende todo mundo pelo mesmo backbone.

As perguntas que valem a reunião com o CTO essa semana

Um apagão de 12 horas no Exchange Online não é motivo para trocar de fornecedor da noite para o dia, mas é motivo suficiente para o board perguntar, com números na mão, o que acontece na próxima vez. Cinco perguntas fazem sentido nessa pauta:

1. Quais sistemas de missão crítica da empresa dependem exclusivamente do Exchange Online, e existe uma via alternativa de comunicação (SMS, WhatsApp Business, um canal fora da Microsoft) para os primeiros minutos de um incidente?
2. O contrato de Enterprise Agreement com a Microsoft prevê SLA de disponibilidade para o Microsoft 365 e, se previr, qual é o crédito financeiro real para um apagão desse porte, comparado ao custo de receita perdida?
3. O time de monitoramento descobre a falha pelo status page oficial da Microsoft ou por observabilidade própria (sintéticos, Downdetector, alertas de usuário)? A diferença de minutos entre as duas fontes já decide o tempo de resposta.
4. Qual processo interno existe para decisões como a da Workhorse Group, adiar uma divulgação de resultado porque o provedor de nuvem caiu, sem que isso vire crise de comunicação com investidores?
5. Qual é o apetite de risco do board para pagar por redundância multi-fornecedor (um segundo provedor de e-mail e colaboração, mesmo que subutilizado) versus aceitar o risco de concentração e pagar o custo quando ele materializa?

O trade-off que ninguém quer bancar

Nenhuma dessas perguntas tem resposta óbvia, e é aí que mora o trabalho de quem decide arquitetura e orçamento junto. Multiplicar fornecedor de e-mail e colaboração custa licença dobrada, treinamento de equipe em duas ferramentas e complexidade de integração que a maioria das empresas despreza até o dia em que o apagão aparece na imprensa.

A alternativa, manter tudo num único fornecedor porque é mais barato e mais simples de operar, é uma aposta racional na maior parte do tempo. O problema é que essa aposta só fica visível quando ela perde, e quando perde, perde para todo mundo ao mesmo tempo: não existe correlação zero entre os clientes de um mesmo backbone de infraestrutura.

Em resumo: o apagão da Microsoft não muda a arquitetura de ninguém da noite para o dia, mas muda o peso de uma pergunta que já devia estar na pauta de continuidade de negócio: quanto vale, em receita e em reputação, uma hora sem e-mail corporativo, e quem no comitê de risco é dono dessa resposta.

Fonte: Exame