Para saber se o seu site WordPress ficou fora do ar antes que um visitante avise, cadastre uma URL pública em um monitor externo, configure quem receberá o alerta e confira se as notificações chegam. Não é preciso instalar um plugin no WordPress para essa checagem básica.
O monitor informa o resultado de requisições feitas à URL escolhida. Mesmo que ela responda normalmente, outras partes do site podem estar com problemas. Abaixo, você verá como configurar o teste, verificar o certificado HTTPS e investigar alarmes sem mexer na produção às cegas.
O que monitorar primeiro?
Em um blog ou site institucional, comece pelo endereço HTTPS definitivo da página inicial. Se uma página pública essencial tiver infraestrutura ou comportamento diferente, considere monitorá-la também. Não escolha como primeiro teste o painel administrativo, checkout com sessão nem páginas protegidas: elas podem exigir autenticação, redirecionar ou devolver 401/403 sem que isso represente queda geral.
Um monitor HTTP consulta a URL em intervalos definidos pela ferramenta. Códigos 2xx indicam sucesso da requisição; 3xx indicam redirecionamento; 4xx, uma resposta de erro relacionada à requisição; e 5xx, falha do lado do servidor. A ferramenta e sua configuração determinam como interpretar redirecionamentos, tempos limite e falhas de TLS. Uma página pode devolver 200 e, ainda assim, mostrar um aviso de manutenção ou conteúdo desatualizado.
A tela Ferramentas > Saúde do site do WordPress ajuda a diagnosticar problemas quando o painel está acessível, mas não substitui o aviso independente de um monitor externo.
Antes de configurar: acesso, privacidade e backup
Você precisa de uma URL pública HTTPS, permissão para cadastrá-la em um serviço externo, acesso ao painel da ferramenta e um e-mail ou canal cujo responsável realmente acompanhe. Abra a URL sem login para conferir o resultado esperado. Se há CDN, firewall ou restrição por região, anote-os para interpretar alarmes depois.
Use um nome de monitor descritivo, mas sem informações sensíveis, como “Site principal — início”. Não inclua senhas, tokens, links de redefinição, dados de pedidos ou parâmetros de sessão na URL ou no nome. Antes de contratar, confira política de privacidade, retenção dos resultados, limites, canais e condições do plano atual.
Cadastrar uma URL no monitor não modifica o WordPress. Se a investigação exigir mudança de cache, firewall, SSL, plugins, DNS ou hospedagem, faça antes um backup restaurável de arquivos e banco de dados, defina um plano de reversão e, se possível, teste em staging. Não derrube a produção para testar o alerta.
Como receber alerta quando o site WordPress cair
O exemplo abaixo segue a documentação de monitores HTTP da Better Stack. Verifique os controles disponíveis na sua conta: interface, frequência, método de notificação e recursos podem mudar. Outros fornecedores oferecem fluxo semelhante, mas não necessariamente as mesmas opções.
- No painel da Better Stack, acesse Monitors > Create monitor e informe a URL pública em URL to monitor. Confira se está configurando um monitor de status HTTP, não um teste de outro tipo.
- Use o endereço HTTPS de produção, por exemplo
https://exemplo.com.br/. Confira se ele abre sem login e se termina no destino esperado após qualquer redirecionamento. - Confira a condição de sucesso, redirecionamentos, tempo limite e frequência permitidos pela conta. Na documentação da Better Stack, o monitor de status HTTP espera resposta 2xx. Não configure “qualquer código é sucesso” apenas para deixar o painel verde.
- Salve o monitor e configure, na área de alertas/plantão aplicável à sua conta, quem receberá incidentes e por qual canal disponível. Confira a primeira checagem e se o responsável de fato recebe notificações; criar o monitor por si só não comprova entrega de e-mail.
- Se houver função de teste de notificação, use-a e confirme a mensagem no canal escolhido. Caso não haja, revise o destinatário e as permissões e, se necessário, teste com uma URL separada sob seu controle, seguindo as regras da ferramenta. Nunca provoque uma queda no site de produção.
Se o site costuma responder 200 mesmo com uma página de erro, considere um monitor de palavra-chave, se disponível. A condição documentada na Better Stack é “URL doesn’t contain keyword”: escolha uma frase pública e estável que deva estar na resposta. Alterações no texto ou no cache podem gerar alarmes enganosos ou esconder falhas. Esse teste não comprova que formulários ou pagamentos funcionam.
Como acompanhar SSL sem confundir validade e vencimento
Verificar se o certificado TLS apresentado ao monitor é válido agora é diferente de receber um aviso antecipado de expiração. Na Better Stack, a verificação SSL/TLS pode ser ativada nas configurações avançadas do monitor; a documentação informa que alertas de expiração exigem plano pago. Confirme os recursos do plano vigente antes de contar com esse aviso. Um certificado que parece válido hoje não garante que a próxima renovação ocorrerá sem falhas.
Sem alerta de expiração na sua conta, acompanhe a renovação pelo painel da hospedagem e faça conferências periódicas. O guia de HTTPS e SSL no WordPress explica o que observar antes de alterar certificados ou redirecionamentos. Vencimento do domínio é uma checagem diferente de expiração do certificado.
Recebi um alerta: queda real ou falso positivo?
Registre horário, URL, código ou erro de conexão, local de checagem (se informado) e duração. Antes de mudar configurações:
- Abra a mesma URL sem login em outra rede, se possível, e confira também uma página pública interna. Uma falha vista em uma região pode não afetar todos os visitantes.
- Consulte os registros da hospedagem, CDN e firewall para o horário do incidente. O firewall pode bloquear o robô e gerar falso positivo; um cache na CDN pode servir uma página antiga enquanto a origem falha, produzindo falso negativo sobre a saúde da origem. Até requisições com métodos HTTP diferentes, como HEAD e GET, podem obter respostas distintas conforme servidor e ferramenta.
- Se houver resposta 500, comece pelo checklist de erro 500 no WordPress e reúna logs e horários antes de alterar plugins ou servidor. Se a instabilidade for recorrente, compare histórico e suporte com os critérios do guia de hospedagem WordPress.
- Se o plano oferecer período de confirmação ou múltiplas regiões de checagem, ajuste-os com critério para reduzir alarmes por oscilação breve. Um período maior também pode atrasar alertas reais. Não silencie permanentemente o monitor só para parar os avisos.
Não compartilhe tokens, logs completos nem capturas com dados pessoais em chamados abertos. Para revisar regras de bloqueio, consulte as camadas de segurança do WordPress e envolva o responsável pela infraestrutura. Antes de qualquer mudança sensível, preserve o estado atual com backup e plano de reversão.
Limites do monitoramento externo
A ferramenta não detecta necessariamente quedas entre duas checagens, formulários quebrados, erros de pagamento, problemas restritos a usuários autenticados nem tarefas em segundo plano. Uma resposta HTTP 200 da CDN não prova que o WordPress na origem está saudável. Páginas protegidas podem retornar 401/403 conforme o visitante; monitorá-las requer outro desenho, com avaliação de segurança, não a exposição de credenciais em URLs.
Revise de tempos em tempos a URL, o canal de alerta e a situação do certificado. Após mudar hospedagem ou CDN, repita a checagem da rota pública. Defina também quem vai investigar, como registrar o incidente e como acionar o suporte: um alerta que ninguém lê não ajuda a recuperar o site.
Perguntas frequentes
Preciso instalar plugin para monitorar uptime do WordPress?
Não para consultar uma URL pública de fora. Um monitor externo continua independente da execução do WordPress; recursos avançados podem exigir configuração e custos adicionais conforme o fornecedor.
“Online” significa que todo o WordPress está funcionando?
Não. Significa apenas que a URL cumpriu as condições configuradas nas checagens feitas. Teste funções essenciais separadamente e investigue reclamações de visitantes mesmo se a página inicial estiver acessível.
Posso testar desligando o site?
Não derrube a produção de propósito. Prefira a função de teste de notificação, quando houver, ou uma URL de teste separada sob seu controle. Para alterações de risco, prepare backup, janela e reversão.
