Quando seu site no Azure App Service para Linux não sobe ou se comporta de forma inesperada, o tempo perdido tentando entender o estado real da aplicação pode custar caro — tanto em SLA quanto em horas de troubleshooting. Até agora, dependíamos de logs, Application Insights e tentativas manuais para descobrir se o problema era startup, configuração ou um nó degradado.
A Microsoft acaba de lançar o Site Status para Azure App Service for Linux, e essa novidade muda o jogo para times que operam aplicações em produção no Brasil. Em vez de chutar, você agora tem um radar de runtime que mostra exatamente o que está acontecendo com seu site.
TL;DR: O Azure App Service para Linux lançou o Site Status, um recurso que revela o estado runtime do seu site — desde "Starting" até "Blocked" ou "Issues Detected". Ele vai além do Health Check tradicional: em vez de depender de um endpoint configurado, usa verificações internas da plataforma para identificar falhas de startup, configuração ou instância. Para empresas brasileiras que rodam aplicações críticas em Azure, isso significa redução de MTTR e mais clareza na hora de decidir entre restart, replace instance ou corrigir infraestrutura.
O que o Site Status mostra — e por que isso importa para o seu time?
Site Status fornece uma visão direta do runtime state do seu web app. Você encontra essa informação na experiência Properties do App Service. Se a plataforma detectar um problema, o status muda para Issues Detected.
Ao clicar em "Issues Detected", uma tela detalhada exibe:
- Status atual do site
- Último erro conhecido (categoria e detalhes)
- Informações adicionais de troubleshooting
- Timestamp do erro
- Ações de reparo disponíveis
Se sua aplicação está com scale-out em múltiplas instâncias, o Site Status mostra esses dados por instância — algo essencial para diagnosticar problemas que afetam apenas um nó.
Isso responde perguntas que todo engenheiro de plataforma já fez:
- Meu site ainda está iniciando?
- Ele subiu com sucesso?
- Está parado ou bloqueado?
- Está em recycling por conta de alguma atualização?
- Qual foi o último erro runtime?
- Esse erro é transiente ou aponta para um problema de configuração?
Quais são os valores de status do Site Status?
| Status | Descrição |
|---|---|
| Starting | O site está inicializando o container e todos os componentes necessários. |
| Started | O site inicializou com sucesso e está rodando. |
| Stopping | O container e os componentes estão sendo desmontados. |
| Stopped | O site não está mais rodando e não receberá requisições. |
| Updating | O site está em recycling (overlapped ou non-overlapped) para aplicar mudanças. |
| Blocked | O site tentou iniciar múltiplas vezes e foi temporariamente bloqueado para reduzir carga nas instâncias. |
| Unknown | Um problema na plataforma está impedindo a avaliação do status. |
Cada um desses estados oferece um ponto de partida claro para a ação. Por exemplo, "Blocked" indica que o site está em crash loop e o Azure está protegendo as instâncias — reiniciar manualmente pode não ser suficiente.
Como interpretar os detalhes de erro?
Quando Issues Detected é acionado, você vê uma tela como esta:
| Campo | O que revela |
|---|---|
| Status | Estado runtime atual do site. |
| Last error | Categoria curta do erro ou tipo de falha. |
| Last error info | Detalhes adicionais para troubleshooting. |
| Last error occurrence | Quando o erro foi observado pela última vez. |
| Actions | Ações de reparo disponíveis. |
O exemplo da documentação mostra um site que falhou porque o storage configurado não pôde ser montado. A mensagem já aponta a causa raiz: não é um problema do processo do site, mas sim de configuração de storage account, file share, firewall, networking, private endpoint ou autenticação. Ou seja, restart ou replace instance não resolveriam — a correção está na infraestrutura, não no app.
Ações de reparo: quando usar?
As ações disponíveis são simples, mas poderosas:
| Ação | Descrição |
|---|---|
| Restart | Reinicia o site na instância selecionada. |
| Replace instance | Move o site para outra instância e substitui a atual. |
Elas são úteis para problemas transientes ou quando a instância subjacente está corrompida. No entanto, não substituem a correção de configuração. Se o seu site não consegue acessar um storage account por conta de regras de rede, restart não vai adiantar. O Site Status ajuda justamente a fazer essa distinção.
Site Status vs. Health Check: quando usar cada um?
É comum confundir os dois, mas eles servem a propósitos complementares:
| Health Check | Site Status |
|---|---|
| Faz ping em um endpoint configurado pelo cliente. | Usa verificações internas da plataforma. |
| Reporta o HTTP status retornado pelo endpoint. | Reporta um status runtime definido pela plataforma. |
| Ajuda a decidir se uma instância deve receber tráfego. | Ajuda a explicar o que está acontecendo com o site em runtime. |
| Requer um health check path configurado. | Não requer endpoint configurado. |
Na prática, você deve usar Health Check para controle de tráfego e Site Status para diagnóstico. Um não substitui o outro — juntos, eles dão visibilidade completa: Health Check garante que instâncias ruins não recebam requisições; Site Status explica por que elas estão ruins.
Resumo: por que isso é relevante para empresas brasileiras?
Se você administra aplicações App Service for Linux no Brasil, o Site Status reduz drasticamente o tempo de diagnóstico. Em vez de navegar por logs ou depender de suporte terceirizado, o time de engenharia tem uma visão imediata do estado runtime, com pistas diretas sobre a causa raiz.
A Microsoft continua melhorando o App Service para Linux com foco em visibilidade e ação. O Site Status é mais um passo nessa direção — e um que todo time de plataforma deveria adicionar ao seu arsenal de observability.
Perguntas Frequentes
-
O que o Site Status mostra que o Health Check não mostra?
Enquanto o Health Check depende de um endpoint HTTP configurado pelo cliente para decidir se uma instância deve receber tráfego, o Site Status usa verificações internas da plataforma. Ele reporta estados como "Starting", "Stopped", "Blocked", "Updating" e exibe o último erro runtime, sem necessidade de configuração adicional. -
Quando devo usar Restart vs. Replace instance no Site Status?
Restart é indicado para problemas transitórios do processo da aplicação. Replace instance é útil quando a instância subjacente está em estado ruim. Porém, nenhum dos dois substitui a correção de configuração — por exemplo, se um storage account não pode ser montado por firewall ou autenticação, restart não resolve. -
Como o Site Status ajuda times de SRE no Brasil?
Com a visibilidade por instância em cenários de scale-out, o Site Status permite identificar rapidamente se o problema é global ou isolado a uma instância. Isso acelera o diagnóstico e reduz o tempo médio de reparo (MTTR), especialmente em ambientes com múltiplas zonas ou regiões. -
Preciso configurar algo para o Site Status funcionar?
Não. O Site Status é nativo do Azure App Service para Linux e não requer configuração de health endpoint ou qualquer custom path. Basta acessar a seção Properties do web app para visualizar o runtime status e, quando aplicável, o link "Issues Detected". -
O Site Status substitui o Application Insights ou logs de diagnóstico?
Não. Ele é complementar. Enquanto Application Insights fornece telemetria de aplicação e logs fornecem detalhes granulares, o Site Status oferece uma visão consolidada do estado runtime da plataforma — ideal para o momento em que o site não sobe ou se comporta de forma inesperada.
Artigo originalmente publicado por TulikaC em Azure Updates - Latest from Azure Charts.
