| Endpoint monitorado | Falha que detecta | Risco se ignorado |
|---|---|---|
| Home (/) | Servidor fora, DNS quebrado, erro 500 global | Nenhum, se for o único monitor: esconde falha parcial |
| Login (/wp-login.php) | Banco indisponível, sessão travada, rate-limit agressivo | Equipe sem acesso ao painel durante incidente |
| Checkout / carrinho | Gateway externo caído, plugin de pagamento em conflito | Venda travada com a home aparentemente no ar |
| API REST (/wp-json) | Headless, app ou integração externa sem resposta | Sincronização e automações silenciosamente paradas |
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. ---Porque o monitor está mal configurado, não porque a ferramenta falhou. Os três motivos mais comuns são: o alerta depende de um plugin interno que cai junto com o servidor, o intervalo de checagem é largo demais (30 minutos), ou o aviso por e-mail caiu na pasta de spam. A correção é usar monitoramento externo, intervalo de 1 a 5 minutos e pelo menos dois canais de notificação, sendo um instantâneo como Slack ou SMS.
Sim, e é a forma mais confiável. Serviços externos como UptimeRobot, Better Uptime e Jetpack Monitor checam seu site a partir de servidores próprios, sem tocar no WordPress. Você só informa a URL e o canal de aviso. Como não dependem de WP-Cron nem de plugin interno, esses monitores continuam funcionando mesmo quando o servidor inteiro está fora do ar, que é exatamente o momento em que o alerta precisa disparar.
O intervalo ideal fica 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, porque 5 minutos de queda no checkout já significam vendas perdidas. Um blog informativo aguenta 5 minutos sem prejuízo real. Evite intervalos de 30 minutos ou mais: eles transformam o alerta em aviso tardio, inútil para reagir a tempo.
O monitoramento básico é gratuito: o UptimeRobot cobre um site com checagem de 5 minutos sem custo. Planos pagos de monitoramento dedicado vão de poucos dólares a algumas dezenas por mês com intervalo de 1 minuto e relatórios. Na plataforma FULL, o monitoramento vem junto com 17 plugins e gestão centralizada: o plano PRO custa R$849 por mês para até 10 sites, cerca de R$85 por site, o que dilui o custo quando você gere vários WordPress de uma vez.
Um bom alerta traz cinco dados na primeira linha: qual URL caiu, o código de erro retornado, o horário exato da falha, há quanto tempo o site está fora e de qual localização foi feita a checagem. Os melhores serviços ainda incluem o TTFB no momento da falha e a resolução de DNS, o que ajuda a distinguir queda de servidor de um problema de rede ou de propagação. Sem esse contexto, o alerta vira só um "site fora" sem ação clara.