Semana passada uma empresa Fortune 500 perdeu cerca de US$ 14 milhões em aproximadamente seis horas porque um único certificado SSL expirou silenciosamente e ninguém percebeu até clientes começarem a reclamar no Twitter. O e-mail de renovação foi enviado. Caiu em uma caixa compartilhada que o antigo líder de DevOps usava. Ele saiu em março. O certificado expirou num sábado às 02:14 UTC. O engenheiro de plantão da plataforma não foi acionado porque tecnicamente nada estava "fora do ar" — o site estava servindo tráfego, só que com um aviso vermelho gigante no navegador que afastava todo cliente pagante.

Esta não é uma história incomum. É a indisponibilidade evitável mais comum que vemos, e ela não tem nada a ver com arquitetura de nuvem ou orquestração de containers. Acontece porque a maioria dos times trata monitoramento de domínio, monitoramento de SSL e monitoramento de uptime como três problemas separados resolvidos por três ferramentas separadas — ou, mais frequentemente, por ninguém. Este guia percorre a stack completa de 3 camadas, o que monitorar em cada camada e como conectar tudo para você nunca mais ser pego de surpresa.

A stack de monitoramento em 3 camadas#

Toda propriedade web pública tem três modos de falha independentes que causam sintomas de "o site está fora", mas exigem remediações completamente diferentes:

Expiração de domínio — seu registro vence, o registrar retoma o domínio e seu DNS para de resolver. Tempo de recuperação: horas a dias. Custo: catastrófico.
Expiração de certificado SSL — DNS continua resolvendo, o servidor continua no ar, mas o certificado passou da data notAfter. Navegadores bloqueiam a conexão. Tempo de recuperação: minutos se automatizado, horas se manual.
Falha de uptime / HTTP — DNS resolve, o cert está válido, mas o servidor retorna 5xx, dá timeout ou foi redirecionado para uma parking page pelo provedor de hospedagem. Tempo de recuperação: depende da causa raiz.

A razão de você precisar das três camadas é que cada uma pega uma falha que as outras ignoram. Monitoramento de uptime te diz que o site está quebrado — mas só depois que o cert SSL já expirou e clientes já cancelaram. Monitoramento de domínio pega o vencimento do registro semanas antes do domínio cair de fato. Monitoramento de SSL pega o problema do cert 30 dias antes do aviso do navegador aparecer. Empilhe os três e você tem defesa em camadas; pule um e você tem um buraco grande o bastante para passar caminhão.

Camada 1: monitoramento de expiração de domínio#

Expiração de domínio é a indisponibilidade mais evitável da internet, e também a mais constrangedora. A Microsoft já fez. O Google já fez (duas vezes). O Foursquare fez. A Sorenson Media fez. Cada uma dessas foi uma indisponibilidade de várias horas causada por um cartão de crédito vencendo no cadastro ou um e-mail de renovação caindo na caixa errada.

Por que e-mails do registrar não bastam#

Registrars enviam lembretes de renovação. Eles vão para o endereço de e-mail que estava no cadastro quando o domínio foi registrado pela primeira vez, que com frequência é o Gmail pessoal de um terceirizado que saiu há três anos. Mesmo quando o endereço está correto, e-mails de registrar caem rotineiramente no spam, e mesmo quando não caem, eles parecem exatamente os e-mails de phishing que fingem ser avisos de renovação, então as pessoas excluem.

Auto-renovação deveria resolver isso, mas falha silenciosamente de três jeitos comuns:

O cartão de crédito cadastrado vence.
O cartão é negado por suspeita de fraude (renovações anuais parecem incomuns para os bancos emissores).
O toggle de auto-renovação do registrar é desligado durante uma migração de conta ou redesign do painel.

Monitoramento externo é o único backup confiável.

Como monitorar a expiração de domínio#

O protocolo é o RDAP (substituto moderno do WHOIS) com fallback para WHOIS em TLDs que ainda não suportam RDAP. Uma checagem diária basta — datas de expiração de domínio não mudam de minuto a minuto, e registrars aplicam seus próprios períodos de carência em cima do que você publica.

# Checagem manual rápida via linha de comando
curl -s "https://rdap.org/domain/example.com" | jq '.events[] | select(.eventAction=="expiration")'

Coloque isso num cron job e você tem um monitor básico. Mas você também precisa de limites de alerta, lógica de retry para falhas transientes de WHOIS e uma forma de detectar a diferença entre "expirado" e "renovado mas a data ainda não propagou". É por isso que uma ferramenta hospedada normalmente é mais rápida do que construir.

A cadência de alertas 30/14/7/2 dias#

Envie alertas em quatro pontos: 30 dias antes (planejamento), 14 dias antes (ação), 7 dias antes (escalada) e 2 dias antes (pânico). Mais frequente do que isso gera fadiga. Menos frequente não deixa folga se o primeiro alerta passar batido.

O que "expirado" realmente significa#

Domínios não caem no segundo em que expiram. A maioria dos TLDs tem um cronograma multi-etapa:

Dia 0–30 após expirar: período de carência. O domínio está suspenso (sem DNS) mas o registrante pode renovar pelo preço normal.
Dia 30–60: período de redenção. Renovação ainda possível mas com taxa de redenção de US$ 80–200.
Dia 60–90: pending delete. O domínio fica travado e não pode ser renovado.
Dia 90+: dropado. Qualquer um pode registrar.

Se um domínio seu entra em redenção, você provavelmente vai pagar mas ainda recupera. Quando entra em pending delete, você está correndo contra drop-catchers profissionais. Não deixe chegar lá.

A Nova Uptime tem um verificador grátis de expiração de domínio para consultas pontuais, e o dashboard roda RDAP diariamente em todo domínio monitorado com a cadência de alerta 30/14/7/2 dias já embutida.

Camada 2: monitoramento de certificado SSL#

Expiração de certificado SSL é, com larga margem, a causa única mais comum de indisponibilidades do tipo "o site está fora". O Microsoft Teams ficou no escuro em fevereiro de 2020 por causa de um certificado de auth expirado. O Microsoft Azure teve uma indisponibilidade de várias horas em 2021 pela mesma causa. Spotify já fez. LinkedIn já fez. Google Voice já fez. O fio condutor: a cadência de rotação de 90 dias do Let's Encrypt treinou a indústria inteira a esperar automação, e quando a automação quebra, ela quebra silenciosamente.

O que de fato monitorar em um certificado#

Um certificado tem mais modos de falha do que só o notAfter. Um monitor completo verifica:

notBefore e notAfter — a janela de validade. Alerte 30, 14, 7 e 2 dias antes do notAfter.
Completude da cadeia do issuer — seu servidor precisa servir a cadeia intermediária completa. Bug comum de deploy: enviar só o leaf certificate; isso funciona no Chrome (que faz cache de intermediários) mas quebra no Firefox, em navegadores móveis e na maioria dos clients de API.
Casamento de Subject e SAN — os Subject Alternative Names do certificado precisam incluir o hostname requisitado. Wildcards são OK mas confirme que o wildcard de fato cobre o subdomínio que você está acessando.
Cipher suite e versão TLS — TLS 1.0 e 1.1 estão depreciados. TLS 1.2 é o piso; TLS 1.3 é preferido. Cifras fracas (RC4, 3DES) devem reprovar seu check.
Presença de OCSP staple — se você configurou OCSP stapling e ele para de funcionar, você verá avisos do navegador mesmo com cert válido.

Modos comuns de falha SSL#

Em ordem aproximada de frequência, as falhas que vemos em produção:

Certificado expirado. O hook de auto-renovação não disparou. O cron morreu. A renovação deu certo mas o novo cert não foi recarregado pelo servidor web.
Certificado intermediário faltando ou errado. O Certbot gera a cadeia mas um script de deploy sobrescreve, ou um reverse proxy é configurado com ssl_certificate em vez de ssl_certificate fullchain.pem.
Hostname não bate. Cert foi emitido para example.com mas o usuário está acessando www.example.com e o SAN não inclui www.
Cert errado servido (bug de SNI). Servidor está hospedando vários sites e o cert do vhost padrão está sendo servido em vez do cert por site.
Drift de relógio. Relógio do servidor está mais que alguns minutos fora, fazendo certs válidos parecerem expirados ou ainda-não-válidos.

Frequência recomendada de check#

Diário é o mínimo. Para endpoints críticos para receita — APIs de pagamento, fluxos de login, widgets embutidos — a cada hora é razoável. O check é barato (um único TLS handshake por endpoint), então frequência raramente é o gargalo.

Desastres reais com certificado#

O padrão se repete todo ano:

Microsoft Teams, fev 2020 — certificado interno expirado derrubou o Teams por horas em pleno horário comercial.
Microsoft Azure, mar 2021 — expiração de cert TLS causou indisponibilidade de 14 horas afetando autenticação em várias propriedades Microsoft.
Spotify, vários anos — certificados expirados causaram pelo menos três indisponibilidades visíveis publicamente.
GitHub status page — em algum momento a própria página de status serviu um cert expirado, que é o tipo de ironia que faz engenheiros rirem nervosamente.

Nenhuma dessas empresas faltava talento de engenharia para evitar a expiração. Faltava o monitoramento em camadas que teria pego. O verificador grátis de expiração SSL da Nova Uptime faz um check pontual; o dashboard roda o mesmo check em agenda e alerta a 30/14/7/2 dias.

Camada 3: monitoramento de uptime / HTTP#

Monitoramento de uptime é a camada que pega tudo o que as duas primeiras não conseguem antecipar: travamentos de servidor, deploys que deram errado, vazamento de memória, esgotamento de pool de conexão de banco, DDoS, problemas do provedor de hospedagem, configuração errada de DNS, envenenamento de cache de CDN e os outros cinquenta modos de falha que não aparecem num cert ou num registro de registrar.

O que verificar#

Um monitor HTTP útil verifica mais do que só "a request retornou 200?". Especificamente:

Status code — qualquer coisa na faixa 2xx é saudável, 3xx pode ser um redirect para parking page (suspeito), 4xx e 5xx são falhas.
Response time — latência p95 subindo é o indicador antecedente de um problema de banco ou CPU.
Conteúdo do response body — idealmente verifique uma string conhecida (um endpoint heartbeat que retorna {"status":"ok"}) para pegar o caso em que o servidor retorna 200 mas a aplicação travou e está servindo página de erro.
Sucesso do TLS handshake — dobra parte da camada 2 no mesmo check.
Tempo de resolução DNS — uma resolução DNS lenta é frequentemente o primeiro sinal de um problema de CDN ou upstream.

Por que múltiplas regiões importam#

Um monitor de região única é uma máquina de falsa confiança. Seu monitor mora em us-east-1. Sua aplicação também. A AWS tem um problema regional. Os dois caem. Seu monitor reporta "site no ar" porque o monitor está morto. Monitoramento multi-região (ou, no mínimo, monitoramento cross-region — monitorar em us-west se sua app está em us-east) elimina essa classe de falso negativo.

Capture screenshots da falha#

Quando um check falha, tire um screenshot da página renderizada. Isso vale ouro em postmortems porque captura exatamente o que o usuário viu no momento da falha — não o que os logs dizem que aconteceu, não o que o monitor sintético acha que aconteceu, mas o que estava na tela. Era um 502? Uma página de manutenção? Uma tela em branco? Um Cloudflare challenge? Você vai saber em dois segundos em vez de duas horas.

Alertas multi-canal#

E-mail é necessário mas não suficiente. E-mail é bufferizado, agrupado e ignorado. Alertas críticos precisam pular o e-mail e chegar a um humano direto. A Nova Uptime suporta e-mail, WhatsApp (Baileys, sem custo por mensagem) e webhooks de saída (assinados com HMAC) para integrar com PagerDuty, Opsgenie, Slack ou qualquer ferramenta de incidente que você use.

Configurando a stack completa com a Nova Uptime#

Aqui está o setup prático, ponta a ponta, mais ou menos na ordem em que você faria.

1. Adicione o domínio#

Cole a URL no dashboard. A Nova Uptime roda um check HTTP imediato, um TLS handshake, uma consulta RDAP/WHOIS para expiração de domínio e um fetch de favicon. Você vê os quatro resultados em até 60 segundos.

2. Configure o intervalo de check#

Plano Free: intervalo de 15 minutos. Plano Pro: até 59 segundos. Plano Agency: o mesmo piso de 59 segundos com mais limites de domínio. Para a maioria dos sites de marketing, checks de 5 minutos estão de bom tamanho. Para APIs de pagamento, checks de 59 segundos são o correto.

3. Conecte o WhatsApp#

Em Configurações → WhatsApp, escaneie o QR code uma vez. A partir daí, todo alerta pode ser enviado para seu número de WhatsApp sem custo por mensagem (plano Free = 1 número, Pro = 3, Agency = 5). Entrega via WhatsApp é mais rápida e mais difícil de ignorar do que e-mail.

4. Adicione e-mails CC para o time#

Na página de configurações de cada domínio, adicione até 5 e-mails em CC. Esta é a lista de distribuição do time para aquele domínio específico — a homepage pode alertar o líder de marketing, a API pode alertar o engenheiro de plantão.

5. Teste alertas com uma falha intencional#

A melhor coisa que você pode fazer depois de plugar o monitoramento é quebrar de propósito uma vez. Aponte uma URL monitorada para um hostname que não existe, ou revogue o cert temporariamente, e veja o alerta disparar. Se não disparar, você acabou de descobrir um bug de configuração na hora mais barata possível.

6. Saiba quando fazer upgrade#

O tier free cobre 5 domínios e basta para projetos pessoais e times pequenos. Os dois motivos para fazer upgrade são: (a) você passou dos 5 domínios, ou (b) você precisa de intervalos de check abaixo de 15 minutos. Detalhes na página de preços.

Estratégia de alertas: evitando fadiga#

O jeito mais rápido de arruinar uma stack de monitoramento é alertar demais. Depois de três falsos positivos numa semana, todo engenheiro do time começa a ignorar o canal, e agora seu monitoramento tem valor negativo.

Três regras de bolso:

Severidade em camadas. Avisos de expiração de domínio a 30 dias são informativos — vão só por e-mail. Avisos de SSL a 7 dias são warnings — e-mail mais um canal no Slack. Site fora por 2+ minutos é crítico — WhatsApp, telefone vibrando, paginar quem está de plantão. Não envie tudo por todo canal.

Pause durante manutenção planejada. Se você está fazendo deploy, rodando uma migração de banco ou girando um cert, pause o monitor relevante na janela de manutenção. A Nova Uptime tem pausa por domínio e um toggle global de "pausar todas as notificações" em Configurações. (O monitoramento continua — só as notificações ficam pausadas, então você pode revisar os logs depois.)

Limite alertas de "ainda fora". Quando um domínio é reportado como fora, você não precisa de notificação a cada minuto. A Nova Uptime envia o alerta inicial e depois lembretes contínuos uma vez por hora (no e-mail e no WhatsApp) até o domínio voltar. O alerta de recuperação dispara sempre na hora.

Roteie por canal. E-mail é bom para digests, relatórios semanais e alertas informativos. WhatsApp é bom para alertas críticos que precisam de um humano nos próximos 5 minutos. Webhooks são bons para automação (criar incidentes do PagerDuty automaticamente, postar no Slack, disparar runbooks).

Alguns casos notáveis que vale conhecer:

LinkedIn, outubro de 2022 — expiração de SSL de várias horas em um subdomínio que afetou entrega de mensagens. O site principal continuou no ar; o problema ficou mascarado até clientes reportarem.
Cloudflare, 2021 — uma má configuração de cadeia de certificado intermediário causou problemas amplos para sites usando o serviço de edge cert da Cloudflare. O leaf cert era válido; a cadeia estava incompleta.
GitHub Status, vários incidentes — a própria página de status já serviu certs expirados ou teve problemas de registro de domínio em vários momentos. A lição é que o meta-monitoramento (a coisa que te diz quando o monitoramento quebrou) também precisa ser monitorado.

Checklist de configuração#

Passe por esta lista e você tem defesa em camadas:

Conclusão#

Monitoramento de domínio, alertas SSL e monitoramento de uptime não são três ferramentas que você parafusa juntas. São três camadas de uma estratégia de defesa em profundidade, e qualquer stack de monitoramento que cobre só uma ou duas vai te decepcionar no pior momento possível. A Nova Uptime te dá as três no mesmo dashboard com alertas por e-mail e WhatsApp no plano free. Cadastre-se grátis e monitore até cinco domínios em menos de cinco minutos.

Leitura relacionada#

Monitoramento de uptime para aplicações SaaS — playbook de monitoramento multi-tenant para times SaaS
Guia de configuração de política DMARC — o complemento do lado de e-mail para monitoramento de domínio
Verificador grátis de expiração de SSL — análise pontual de certificado
Verificador grátis de expiração de domínio — consulta RDAP/WHOIS com status de período de carência
Verificador grátis de email health — confira se seus e-mails de alerta estão chegando

Monitoramento de Domínio com Alertas SSL: o Guia Completo de 2026