Monitoramento de uptime 24h para site de emergências em Parque São Lucas

Às 3h17 da madrugada de uma terça-feira, o telefone de plantão da equipe de infraestrutura vibrou. O site de emergências de uma desentupidora 24h no Parque São Lucas estava fora do ar há 23 minutos — tempo suficiente para perder dezenas de chamados de alagamentos e entupimentos críticos. O monitoramento básico do provedor de hospedagem só disparou alerta às 3h40, quando o cliente já havia ligado reclamando. Esse cenário real expõe a fragilidade de confiar apenas em verificações superficiais de HTTP 200.

Um site de emergências não pode tratar uptime como métrica de vaidade. Cada minuto de indisponibilidade representa alguém com água na sala, esgoto retornando pelo ralo ou risco sanitário imediato. A arquitetura de monitoramento precisa validar não apenas se o servidor responde, mas se o botão “Chamar WhatsApp” carrega, se o formulário de orçamento envia dados, se o telefone clicável funciona no mobile. Em situações de pânico, o usuário não recarrega a página — ele vai para o concorrente.

A seguir, detalhamos a estratégia completa que implementamos para garantir 99,9% de disponibilidade real, com detecção em segundos, alertas inteligentes e failover testado. A abordagem combina monitoramento sintético, real user monitoring (RUM), health checks de aplicação e integração direta com a equipe de plantão.

Arquitetura de monitoramento em camadas

A base sólida exige três camadas independentes: infraestrutura, aplicação e negócio. Na camada de infraestrutura, monitoramos DNS (resolução e propagação), TCP/SSL handshake, expiração de certificado, latência de rede e saúde do load balancer. Ferramentas como UptimeRobot, Pingdom ou Better Uptime cobrem esse nível, mas sozinhas são insuficientes.

A camada de aplicação executa health checks funcionais a cada 30 segundos: requisição GET na home, POST no formulário de emergência, validação de seletores CSS do botão WhatsApp, verificação de headers de segurança (HSTS, CSP) e medição de TTFB. Usamos scripts Playwright rodando em containers Kubernetes distribuídos em três regiões AWS (sa-east-1, us-east-1, eu-west-1) para eliminar falsos positivos de rota de rede.

A camada de negócio correlaciona métricas reais de usuários (RUM via web-vitals library) com conversões: taxa de cliques no botão de emergência, tempo até envio do formulário, erros de JavaScript que quebram o fluxo. Se o LCP sobe acima de 3s ou a taxa de erro JS passa de 1%, o alerta dispara antes mesmo de o site cair. Para integração com a equipe de campo, recomendamos o uso de webhooks conectados ao sistema de chamados — veja como estruturamos isso em Área do cliente para histórico de manutenções em Moema.

Alertas inteligentes: reduzindo ruído sem perder críticas

O maior inimigo do plantão é o alert fatigue. Configuramos políticas de alerta com três princípios: confirmação multi-checkpoint, janelas de silenciamento e enriquecimento de contexto. Cada alerta exige falha confirmada em pelo menos 2 de 3 regiões de monitoramento, com intervalo mínimo de 60s entre checks — isso elimina 94% dos falsos positivos de instabilidade de rede momentânea.

Janelas de manutenção programadas (deploy, backup, rotação de logs) silenciam alertas automaticamente via API do sistema de monitoramento, integrada ao pipeline CI/CD. O enriquecimento anexa ao alerta: runbook específico do incidente, dashboard de métricas correlacionadas, contatos de escalação e últimos 3 deploys. A equipe recebe uma mensagem única acionável, não um flood de notificações.

A rotação de plantão segue modelo “follow the sun” adaptado: dois engenheiros por turno de 12h, com escalação automática para tech lead se não houver ACK em 2 minutos. O runbook de cada tipo de incidente (banco lentidão, CDN fora, deploy quebrado) fica versionado no repositório Git com acesso offline via app móvel. Essa estrutura evita o cenário caótico onde ninguém sabe quem deve agir ou qual procedimento seguir.

Página de status pública e comunicação transparente

Durante incidentes, a comunicação transparente reduz pressão no suporte e mantém confiança. Implementamos página de status (status.clientesite.com.br) com: indicador geral (verde/amarelo/vermelho), lista de incidentes ativos com timestamp e tempo decorrido, histórico de 90 dias com pós-mortem resumido, métricas de uptime mensal (meta 99,9% = 43min downtime/mês), e — crucial para emergências — botões diretos para WhatsApp, telefone 0800 e formulário alternativo hospedado em domínio separado.

A página é estática (Next.js export + Cloudflare Pages) para permanecer online mesmo se a infraestrutura principal falhar. Atualizações vêm de webhook do sistema de monitoramento para API da página de status, sem intervenção manual. O pós-mortem de cada incidente >5min é publicado em até 24h com: causa raiz (5 Whys), impacto real (chamados perdidos estimados), ações corretivas e preventivas com donos e prazos.

Essa transparência também serve como ferramenta de vendas: clientes B2B avaliam maturidade técnica pelo histórico de incidentes e qualidade dos pós-mortem. Para entender como estruturar métricas de conversão que alimentam essa visão, consulte Analytics de conversão para leads de desentupimento no Mandaqui.

Failover testado: do caos à confiança

Teoria de failover não sobrevive ao primeiro incidente real. Adotamos chaos engineering mensal: simulamos falhas controladas em staging idêntico ao produção (mesma AMI, mesmo Terraform, mesmos secrets via Vault). Cenários testados: instância RDS derrubada, DNS do ALB removido, CPU saturada em 100%, certificado SSL expirado, rede particionada entre AZs. Cada teste valida RTO < 5min e RPO < 1min (replicação síncrona Multi-AZ + backup point-in-time).

O runbook de failover documenta: comando exato para promover réplica RDS, atualização de Route53 health check, verificação de variáveis de ambiente na nova instância, teste de smoke test automatizado (Playwright), notificação de status page e comunicação para equipe de plantão. Após cada exercício, atualizamos o runbook com lições aprendidas — tempo real gasto, comandos que falharam, gaps de permissão IAM.

A migração de servidor sem downtime que executamos recentemente para um cliente na Penha validou essa abordagem na prática: 47 minutos de janela, zero downtime percebido, DNS propagado em <2min via TTL 60s pré-configurado. Detalhes em Migração de servidor sem downtime para site da Penha.

Core Web Vitals como indicadores de confiabilidade

Em sites de emergência, Core Web Vitals não são SEO — são métricas de segurança. LCP > 2,5s significa que o botão “Ligar agora” não apareceu a tempo para alguém em pânico. FID > 100ms indica que o JavaScript bloqueia o clique no WhatsApp. CLS > 0,1 causa cliques acidentais em anúncios ou links errados. Monitoramos essas métricas no 75º percentil (p75) via RUM contínuo, com alerta se p75 LCP > 3s por 5min consecutivos.

A otimização focou em: critical CSS inline, preload de fontes e hero image, defer de JS não-crítico, service worker para cache offline do formulário de emergência, e CDN com edge locations no Brasil (Cloudflare + CloudFront). O service worker permite que o usuário preencha o formulário mesmo com conexão instável — o dado sincroniza quando a rede volta. Essa resiliência offline é diferencial em áreas com cobertura móvel precária durante tempestades.

Para implementação técnica de blocos Gutenberg que carregam apenas o necessário e mantêm performance, veja Como criar blocos Gutenberg dinâmicos com React.

Integração com a operação de campo: fechando o loop

O monitoramento só gera valor se a equipe de campo souber agir. Integramos via webhook bidirecional: monitoramento → sistema de chamados (criação automática de ticket com prioridade “Emergência Site”), e sistema de chamados → monitoramento (marcação de janela de manutenção quando equipe agenda visita preventiva ao datacenter do cliente).

A equipe de plantão recebe no app móvel: tipo de falha (infra/app/negócio), runbook linkado, dashboard ao vivo, botão “Reconheci” e “Escalonar”. Se o ticket não for atualizado em 10min, escalação automática para gerente de operações. Pós-incidente, o técnico preenche campo “Ação corretiva” que alimenta base de conhecimento para runbooks futuros.

Essa integração elimina o gap clássico: infra detecta, mas ninguém da operação sabe; ou operação resolve, mas monitoramento continua alertando. Para ver como estruturamos autenticação segura nessa integração via REST API, consulte Autenticação via Application Passwords na REST API.

Conclusão prática

Monitoramento de uptime 24h para emergências não é configuração única — é disciplina operacional contínua. Camadas independentes, alertas enriquecidos, failover testado mensalmente, página de status transparente e integração bidirecional com a equipe de campo formam o sistema que garante que, às 3h17 da madrugada, o botão de emergência funcione. Comece implementando health check funcional hoje, adicione RUM na próxima sprint, agende o primeiro chaos experiment para daqui duas semanas. A disponibilidade real se constrói em camadas, não em promessas de SLA do provedor.

Para conhecer a estrutura completa de atendimento de emergências na região, acesse dezjatodesentupidora.com.br/desentupidora-no-parque-sao-lucas.

Checklist prático

Perguntas frequentes

Qual a diferença entre monitoramento básico e monitoramento 24h profissional?

O monitoramento básico verifica apenas se o site responde HTTP 200 em intervalos longos. O profissional testa conteúdo crítico, tempo de resposta, SSL, DNS e dispara alertas em segundos via múltiplos canais (SMS, WhatsApp, e-mail, webhook).

Como configurar alertas que não gerem ruído desnecessário?

Defina thresholds realistas (ex.: >3s para TTFB, >5% taxa de erro), use janelas de manutenção programadas, agrupe alertas correlacionados e exija confirmação em 2 checkpoints geográficos distintos antes de notificar a equipe de plantão.

O que deve conter em uma página de status pública para emergências?

Status geral (operacional/degradado/fora do ar), incidentes ativos com tempo decorrido, histórico de 30 dias, métricas de uptime (99.9% = 43min/mês de downtime), e links diretos para canais de emergência alternativos (telefone, WhatsApp).

Como testar o failover sem derrubar o site de produção?

Use ambiente de staging idêntico ao produção, simule falhas com chaos engineering (desligar instância, bloquear DNS, saturar CPU), valide RTO/RPO e documente runbooks. Agende testes mensais em janela de baixo tráfego.

Quais métricas de Core Web Vitals impactam diretamente a confiabilidade em emergências?

LCP < 2.5s garante que o botão de chamada de emergência carrega rápido; FID < 100ms assegura interação imediata; CLS < 0.1 evita cliques acidentais. Em situações de pânico, milissegundos definem se o usuário consegue acionar o socorro.

Como integrar monitoramento com a equipe de plantão da desentupidora?

Configure webhooks para o sistema de chamados da equipe, use rotação de plantão com escalonamento automático (se não houver ACK em 2min, escala para supervisor), e mantenha runbooks versionados no repositório do projeto com acesso offline.