Service Health do Microsoft 365: o guia do painel de integridade do serviço

Quando o Outlook trava, o Teams cai ou o e-mail para de enviar, a primeira pergunta certa não é "como conserto?", é "o problema é meu ou da Microsoft?". O painel que responde isso se chama Service Health (Integridade do serviço), e ele fica dentro do centro de administração do Microsoft 365. É a ferramenta que todo administrador deveria conhecer antes de abrir o primeiro chamado. Este guia explica o que é, onde fica, como ler o que ele mostra e, o mais importante, o que ele não enxerga.

1. O que é o Service Health

O Service Health, em português, Integridade do serviço, é o painel oficial onde a Microsoft comunica, em tempo real, os problemas que afetam os serviços do Microsoft 365 no seu tenant: Exchange Online, Teams, SharePoint, OneDrive, Entra ID (identidade), Purview, Power Platform e os demais workloads que você licencia.

Ao contrário de um site genérico de "está fora do ar", o Service Health é específico da sua organização: ele mostra apenas os incidentes que a Microsoft correlacionou ao seu ambiente. Se um serviço está degradado só em outra região ou para outro conjunto de clientes, ele não vai aparecer poluindo o seu painel. Isso o torna a fonte definitiva para decidir se a origem do problema é a plataforma.

2. Onde fica e quem pode acessar

O painel está no centro de administração do Microsoft 365, em admin.cloud.microsoft, no menu Integridade (Health) → Integridade do serviço (Service Health). O atalho direto é admin.cloud.microsoft/#/servicehealth.

O acesso exige uma conta com permissão administrativa. Não precisa ser Administrador Global: a Microsoft tem um papel específico e de baixo privilégio chamado Leitor de integridade do serviço (Service Support Administrator / Service Health), que permite ver os incidentes sem dar poder de mudar nada no tenant, ideal para quem só precisa acompanhar.

Quem não tem acesso administrativo nenhum ainda pode usar a versão pública, o status.cloud.microsoft, que dá a visão geral dos serviços sem login, útil para uma primeira confirmação.

3. Os três tipos de aviso: incidente, advisory e Message Center

Nem tudo que aparece no painel é uma queda. Confundir os tipos gera pânico desnecessário, ou faz ignorar o que importa. São três categorias:

Tipo	O que é	Impacto típico
Incidente (Incident)	Interrupção real: serviço indisponível ou degradado de forma perceptível.	Alto, trava ou atrapalha o uso para vários usuários.
Aviso (Advisory)	Problema menor, com solução alternativa ou afetando poucos usuários.	Baixo/médio, vale acompanhar, raramente para a empresa.
Message Center	Não é falha: são mudanças planejadas, novos recursos, alterações e depreciações.	Futuro, afeta o tenant nas próximas semanas/meses.

O Message Center merece atenção especial: é ali que a Microsoft avisa, com antecedência, sobre mudanças que vão alterar o comportamento do seu ambiente. Ignorá-lo é o que faz uma atualização da Microsoft "quebrar" um fluxo sem que ninguém tenha sido pego de surpresa, na verdade, o aviso estava lá.

4. Anatomia de um incidente

Ao clicar em um incidente, o Service Health mostra um conjunto padronizado de informações. Saber lê-las é o que separa "acho que caiu" de uma comunicação precisa para a diretoria:

• Identificador: um código como EX123456 (EX = Exchange, TM = Teams, SP = SharePoint, MO = múltiplos serviços). Serve para acompanhar e referenciar o caso.
• Título e serviço afetado: qual workload e o resumo do problema.
• Estado atual: a fase em que o incidente está (veja abaixo).
• Impacto ao usuário: o que, na prática, os usuários não conseguem fazer.
• Histórico de atualizações: a linha do tempo com as mensagens da Microsoft e a próxima previsão de atualização.

Os incidentes costumam evoluir por fases previsíveis, que vale reconhecer:

1. Investigando (Investigating): a Microsoft identificou um possível problema e está apurando.
2. Degradação / Interrupção do serviço: o impacto foi confirmado.
3. Restaurando o serviço (Restoring): a correção está sendo aplicada.
4. Serviço restaurado (Service restored): resolvido; muitas vezes seguido de um relatório pós-incidente (PIR) com a causa raiz.

5. O que o Service Health NÃO enxerga

Aqui está o limite mais importante, e o mais mal compreendido. O Service Health mostra apenas problemas da plataforma Microsoft. Ele é cego para tudo que acontece do seu lado da conexão:

• Sua internet, VPN, proxy ou firewall bloqueando o acesso.
• Um registro DNS incorreto (MX, autodiscover, SPF, DKIM) derrubando o e-mail.
• Um antivírus ou uma atualização de sistema travando o Outlook em uma máquina.
• Uma política de acesso condicional mal configurada bloqueando logins.
• Uma licença expirada ou mal atribuída a um usuário.

Por isso a regra de ouro: se o Service Health está limpo e o problema persiste, a causa está no seu ambiente, e não adianta esperar a Microsoft resolver. Montamos uma página dedicada a esse diagnóstico, com um console das fontes oficiais e o passo a passo para diferenciar os dois lados: o Microsoft 365 está fora do ar?.

6. Notificações: não fique olhando o painel

Ninguém deveria abrir o portal de hora em hora para descobrir se algo caiu. O próprio Service Health, em Preferências, permite configurar notificações por e-mail para novos incidentes e advisories dos serviços que você escolher. É o mínimo para não ser pego de surpresa.

Em ambientes mais maduros, dá para ir além e integrar esses eventos a um fluxo de operação, por exemplo, encaminhar automaticamente cada novo incidente para um canal do Teams ou para o sistema de chamados, via a API de comunicação de serviço do Microsoft Graph. Assim, o alerta vira ação, e não mais um e-mail que ninguém lê.

7. Como um MSP transforma isso em operação

Checar o Service Health resolve o momento da crise. Mas o valor de uma operação gerenciada está em não descobrir a queda pelo usuário reclamando. No modelo de Serviços Gerenciados, monitoramos o Service Health e o Message Center de forma contínua: identificamos o incidente, comunicamos o impacto e o prazo, aplicamos workarounds quando existem e acompanhamos a resolução com a Microsoft. E quando o painel está verde mas o problema persiste, investigamos o seu ambiente e resolvemos na causa, porque conhecer o Message Center com antecedência também evita que mudanças da plataforma quebrem algo sem aviso.

Essa leitura contínua do ambiente é, aliás, parte do que avaliamos num health check de tenant: se as notificações estão configuradas, quem tem acesso ao painel e como a empresa responde a um incidente.

Conclusão

O Service Health é a diferença entre reagir no escuro e responder com precisão. Ele diz, em minutos, se a origem do problema é a Microsoft, e, quando não é, aponta que a investigação precisa virar para o seu lado. Saber ler esse painel já coloca qualquer administrador à frente. Transformá-lo em monitoramento proativo, com alguém de olho antes do chamado, é o que separa apagar incêndio de operar com método.

Se quiser, fazemos um assessment do seu ambiente Microsoft e mostramos, sem compromisso, como está a sua resposta a incidentes, do acesso ao painel às notificações e ao plano de ação.