Alertas de downtime avisam no minuto em que seu WordPress sai do ar, antes do cliente perceber. Segundo a Cloudflare Learning (2024), 99,9% de uptime ainda deixa o site quase 9 horas fora do ar por ano. Um intervalo de checagem de 1 minuto detecta a queda em segundos, não em horas. Comece monitorando home, login e checkout separados.

Alertas de downtime são notificações automáticas disparadas quando um serviço de monitoramento detecta que seu site parou de responder. O conceito é simples: uma máquina externa tenta abrir uma URL sua a cada poucos minutos e, se a resposta falhar, você recebe um aviso por e-mail, SMS, Slack ou push. O problema raramente é a ferramenta. É a configuração. A maioria dos sites monitora só a home, com intervalo largo demais, por um canal só, que acaba no spam. O resultado é o pior cenário para quem gere sites: descobrir a queda pelo cliente irritado, não pelo alerta. Este guia faz parte da nossa central de conteúdos de gestão de sites WordPress e mostra como configurar alertas de downtime que realmente avisam a tempo.

O que monitorar antes de configurar alertas de downtime

Antes de ligar qualquer alerta, defina os três pontos de falha que importam: home, autenticação e conversão. Em 5 minutos de auditoria você descobre que monitorar só a home cobre talvez metade do risco. Um WooCommerce com a home no ar e o checkout quebrado segue “online” no status 200, mas perde venda.

É esse downtime parcial que os alertas de downtime mal configurados não pegam. A tabela abaixo separa o que cada endpoint revela e serve de checklist ao montar seus monitores.

Legenda: três monitores distintos cobrem os pontos de falha que um único ping na home deixa passar.

Monitoramento interno x externo: Por que o wp-cron não basta

O monitoramento externo é a única forma confiável de gerar alertas de downtime, porque não depende do site vigiado. Plugins internos do WordPress usam o WP-Cron, mas há um furo fatal: se o servidor cai, o WP-Cron cai junto e nunca dispara o aviso. É o alarme de incêndio ligado na mesma energia do prédio que pega fogo.

Por isso serviços como UptimeRobot, Better Uptime e Jetpack Monitor consultam seu site a partir de servidores próprios, externos à sua infraestrutura. Eles seguem o padrão documentado pelos WordPress Developer Docs, que reconhecem o WP-Cron como agendador interno dependente de tráfego, não como sentinela de disponibilidade. A regra prática: use plugin interno para tarefas de manutenção e use um monitor externo para os alertas de downtime que precisam funcionar justamente quando tudo o mais falhou.

Como configurar alertas de downtime em 5 passos

Configurar alertas de downtime confiáveis leva cerca de 15 minutos e segue cinco passos: escolher a ferramenta, definir endpoints, ajustar o intervalo, configurar canais redundantes e validar com um teste real. A ordem importa, porque um intervalo errado ou um canal único derruba a confiabilidade de todo o resto. Faça os cinco antes de considerar o monitoramento pronto.

Passo 1: Escolha a ferramenta de monitoramento externo

Comece por uma ferramenta externa gratuita ou paga conforme o intervalo que você precisa. UptimeRobot oferece checagem a cada 5 minutos no plano gratuito e 1 minuto no pago; Better Uptime e WP Umbrella entregam 30 segundos a 1 minuto com painel e relatórios. Para quem gere muitos sites, ManageWP centraliza o status de todos num painel só. Escolha pela frequência de checagem e pelos canais de notificação, não pela quantidade de gráficos bonitos.

Passo 2: Defina os endpoints críticos, não só a home

Cadastre pelo menos três monitores: home, login e a URL de conversão. Para o checkout, use checagem por palavra-chave: o monitor não confere só o status 200, ele verifica se uma string esperada (“Finalizar compra”, por exemplo) está no HTML. Assim, uma página que carrega meio quebrada, com status 200 mas sem o botão de pagamento, ainda dispara alertas de downtime. Esse detalhe pega o downtime parcial que derruba venda sem derrubar o servidor.

Passo 3: Ajuste o intervalo de checagem ao seu risco

Defina o intervalo entre 1 e 5 minutos conforme o custo de cada minuto fora do ar. Uma loja em horário de pico justifica checagem de 1 minuto; um blog informativo aguenta 5. Cuidado com o falso positivo: se o servidor reinicia o PHP-FPM em 90 segundos durante um deploy, um monitor de 1 minuto pode acusar queda que já se resolveu. Configure o gatilho para confirmar a falha em duas checagens seguidas antes de alertar.

Passo 4: Configure canais redundantes de notificação

Nunca dependa de um único canal de aviso. Configure no mínimo dois: e-mail mais um canal instantâneo como Slack, Telegram, SMS ou push do app. O motivo é direto: alerta por e-mail único somado a uma caixa que filtra notificação automática como spam resulta em downtime descoberto só horas depois. Com Slack ou SMS em paralelo, a equipe vê o aviso no celular em segundos. Para times, aponte o webhook para o canal de plantão, não para a caixa pessoal de uma pessoa.

Passo 5: Valide com um teste de queda controlado

Force uma falha controlada e confirme que o alerta chega. Coloque o site em ambiente de staging, pare o serviço web por 2 minutos e cronometre quanto tempo até o aviso pingar no seu celular. Esse teste revela o que a documentação não conta: canais bloqueados, atraso real de entrega, e-mails que vão para promoções. Um alerta que você nunca testou não é um alerta, é uma suposição.

O que um bom alerta de downtime precisa informar

Um alerta útil traz cinco dados em uma linha: qual URL caiu, o código de erro, o horário exato, há quanto tempo está fora e de onde foi checado. Sem isso, você recebe um “site fora do ar” inútil às 3h da manhã e perde 10 minutos só descobrindo o que houve.

A diferença entre um alerta bom e um ruído é a densidade de contexto na primeira linha da notificação.

Os melhores serviços incluem ainda o TTFB no momento da falha e a resolução de DNS, o que ajuda a separar queda de servidor de problema de rede. A gente vê no suporte da FULL que boa parte dos chamados de “site fora” são, na verdade, picos de latência ou propagação de DNS, não queda real. Um alerta que distingue os dois economiza correria à toa e acelera o diagnóstico do incidente verdadeiro.

Como integrar alertas de downtime à rotina de gestão

Alertas de downtime isolados resolvem o aviso, mas não a operação. O ganho real aparece quando a queda vira registro: cada incidente entra num histórico que alimenta o relatório de manutenção e expõe padrões, como o site que cai sempre depois de uma atualização automática. Sem esse registro, você apaga incêndios sem nunca descobrir o curto-circuito.

Para quem administra vários sites, o caminho é consolidar tudo num painel de gestão de sites que mostre o status de todos lado a lado, em vez de pular entre dez abas. Conecte os alertas de downtime ao seu checklist de manutenção e ao processo de monitoramento de uptime contínuo. Defina também um responsável de plantão por janela de horário, para que o aviso não fique órfão de madrugada. Disponibilidade não é evento, é métrica que você acompanha ao longo do tempo.

Quanto custa monitorar e quando vale o painel da FULL

Monitorar downtime sai de graça a alguns reais por site no nível básico, mas o custo real aparece na fragmentação. Ferramentas gratuitas como UptimeRobot resolvem 1 site; quando você administra dez, vinte ou cem, pular entre painéis avulsos vira o gargalo de quem gere a operação.

É aí que a plataforma FULL entra como alternativa: além de monitoramento, ela reúne 17 plugins premium e gestão centralizada numa assinatura só. O plano PRO da FULL custa R$849 por mês e cobre até 10 sites, o que dá cerca de R$85 por site, com os alertas, o backup e a manutenção no mesmo lugar. A gente vê no suporte que esse é o ponto em que quem gere muitos sites para de remendar ferramentas soltas e passa a tratar disponibilidade como processo, não como apagão pontual. O cálculo já fica favorável a partir de quatro ou cinco sites sob gestão. Conheça em FULL.services/planos.

Erros comuns que silenciam seus alertas de downtime

O erro mais caro é confiar num intervalo largo com canal único: checagem a cada 30 minutos por e-mail só pode atrasar a descoberta da queda em meia hora ou mais. Em uma loja, isso é venda perdida que não volta. O segundo erro é monitorar apenas a home e achar que o site inteiro está coberto, ignorando checkout e login.

O terceiro erro aparece em ambientes específicos. Em VPS com menos de 2 GB de RAM rodando WooCommerce com catálogo acima de 1.000 produtos, o servidor reinicia o PHP-FPM sob pico de tráfego e gera falsos positivos em monitores de 30 segundos. A configuração que estabiliza nesses casos é confirmar a falha em duas checagens consecutivas e apontar um segundo monitor para a URL do carrinho com palavra-chave esperada. Esse ajuste separa o soluço momentâneo do servidor de uma queda real que merece acordar a equipe.

Perguntas frequentes sobre alertas de downtime

Próximos passos para nunca mais ser pego de surpresa

Alertas de downtime bem configurados mudam a relação com a queda: você deixa de descobrir o problema pelo cliente e passa a agir antes do prejuízo. O resumo operacional é direto: monitore home, login e checkout em separado, use uma ferramenta externa com intervalo de 1 a 5 minutos, configure dois canais de aviso e teste a queda de verdade antes de confiar no sistema. Depois, transforme cada incidente em registro para enxergar padrões em vez de só apagar incêndios.

Para continuar aprendendo a manter seus sites no ar, o FULL Academy reúne os tutoriais, guias e checklists de gestão WordPress num só lugar. Comece pelo seu site mais crítico, configure os cinco passos hoje e durma sabendo que o aviso chega antes do cliente.