monitoramento de WordPress

Monitore cada site WordPress que você administra

Nada para instalar no site. O Uptimepage verifica cada site WordPress de fora, numa página que o cache não consegue servir sozinho, e avisa você no Slack ou por e-mail quando algo quebra o site, geralmente antes que o dono do site tenha percebido.

Comece grátis

Verifique uma página que o cache não consegue servir

A maioria dos sites WordPress tem um cache de páginas na frente do PHP, vindo de um plugin, da hospedagem ou de uma CDN. Isso é bom para os visitantes e ruim para o monitoramento: o cache pode continuar servindo a página inicial enquanto o PHP caiu e o banco de dados está inacessível, então uma verificação na página inicial fica verde durante toda a queda. Mantenha a verificação da página inicial, porque é o que os visitantes veem, e adicione outra numa página que o cache ignora, como /wp-json/, o índice da API REST. Ela não consegue responder sem o PHP e o banco de dados, então, quando falha, foi o WordPress que falhou. Se um plugin de segurança fecha a API REST para visitantes, ela responde 401 ou 403, o que ainda prova que o PHP e o banco de dados funcionam, então configure a verificação para esperar esse código. Alguns plugins de cache e algumas hospedagens também colocam essa página em cache; se for o seu caso, use qualquer outra página que o seu cache exclua.

Um 200 não prova que é o seu site

Uma página em branco pode voltar como 200. Também pode a página de estacionamento que o registrador coloca no ar depois de uma renovação esquecida, ou um site invadido que redireciona para o de outra pessoa. Dê à verificação uma frase que só a sua página real contém, como o nome do site no rodapé, e uma resposta sem ela conta como fora do ar, seja qual for o código de status.

As atualizações rodam quando ninguém está olhando

Desde o WordPress 5.5, plugins e temas podem se atualizar sozinhos, e as atualizações em segundo plano rodam duas vezes por dia, tenha alguém olhando ou não. Desde a versão 6.6, o WordPress reverte uma atualização de plugin que cause um erro fatal. Uma atualização que quebra uma página sem erro fatal continua no ar, e quem percebe é a verificação do conteúdo ou um fluxo de navegador. Num monitor verificado de várias regiões, uma falha passageira vista de uma região só não aciona ninguém por padrão, então o alerta que você recebe é sobre o site e não sobre um caminho de rede ruim. Quando for atualizar manualmente, agende antes uma janela de manutenção, e os alertas desse site ficam suspensos até ela terminar.

Uma loja que carrega mas não vende

Numa loja WooCommerce, a página inicial e as páginas de produto podem carregar normalmente enquanto uma atualização, um plugin de pagamento ou uma troca de tema quebrou o carrinho ou o checkout. Uma verificação de fluxo de navegador percorre o caminho de um comprador, até a cada cinco minutos: abre um produto, adiciona ao carrinho, vai ao checkout e confirma que o botão “Place order” (finalizar pedido) está lá. Escolha um produto com o gerenciamento de estoque desativado, porque o checkout em blocos reserva o estoque do carrinho por alguns minutos cada vez que carrega. Quando uma etapa falha, o resultado indica qual foi, então você sabe que o problema é o checkout e não o site inteiro. Quantas verificações de fluxo você tem depende do plano.

O WP-Cron espera por visitantes

Posts agendados, plugins de backup e as tarefas em segundo plano do WooCommerce esperam pelo WP-Cron, e o WP-Cron só começa quando uma visita carrega o WordPress. Visitas que o cache de páginas responde nunca o carregam, então um site com cache só roda o WP-Cron nas visitas que escapam do cache. Sites que o desligam com DISABLE_WP_CRON dependem de um cron do sistema, e essa linha é fácil de perder numa migração de servidor. De um jeito ou de outro, nada dá erro. O primeiro sinal é um post marcado como “Missed schedule” (agendamento perdido) ou uma pasta de backup que parou de crescer há semanas. Uma verificação de heartbeat transforma esse silêncio em alerta: rode o WP-Cron pelo cron do sistema, faça um ping na URL do heartbeat logo depois e, quando os pings pararem, você fica sabendo.

Certificados e domínios vencem em silêncio

A renovação do Let's Encrypt costuma quebrar depois de uma mudança de DNS ou de uma migração de servidor, e ninguém percebe até os navegadores mostrarem um aviso. Domínios de clientes muitas vezes ficam na conta do próprio cliente no registrador, pagos com um cartão que venceu no ano passado. Uma verificação TLS avisa antes de o certificado vencer. Configure o aviso alguns dias abaixo do ponto em que a sua renovação roda, para que uma renovação normal passe em silêncio e só uma que falhou chegue até você. Uma verificação de vencimento de domínio avisa 30 dias antes de o registro terminar, o que deixa tempo para ligar para o cliente.

Páginas de status que seus clientes podem abrir

Um cliente pode ter uma página de status com a própria marca e só os sites dele. Os incidentes são publicados nela conforme as verificações falham, então, quando um cliente perguntar o que aconteceu ontem à noite, você manda um link.

Uma lista de clientes sem um formulário por site

O formulário dá conta dos primeiros sites. Para uma lista inteira de clientes, o provider do Terraform, a API REST e o servidor MCP criam os monitores de uma vez só, com as mesmas verificações e os mesmos canais de alerta em cada um, e, com o Terraform, a lista fica num arquivo que você pode revisar.

Um crontab para o usuário dono do site. Defina o período do heartbeat igual ao intervalo do cron, aqui 5 minutos, com 5 minutos de tolerância

# Primeiro adicione ao wp-config.php: define( 'DISABLE_WP_CRON', true );
# Rode como o usuário do site, não como root: o WP-CLI se recusa a rodar como root.
URL=https://app.uptimepage.dev/ping/your-token
*/5 * * * * cd /var/www/example.com && /usr/local/bin/wp cron event run --due-now --quiet; curl -fsS -o /dev/null "$URL/$?"

# Hospedagem compartilhada sem WP-CLI: coloque isto no campo de cron da hospedagem,
# no menor intervalo que ela permitir, e ajuste o período do heartbeat a ele.
# curl -fsS -o /dev/null "https://example.com/wp-cron.php?doing_wp_cron" && curl -fsS -o /dev/null https://app.uptimepage.dev/ping/your-token

Perguntas frequentes

Como monitorar um site WordPress?

Adicione duas verificações HTTP: uma na página inicial e outra numa página que o cache ignora, como /wp-json/, o índice da API REST. A página inicial mostra o que os visitantes recebem, e a página sem cache mostra se o PHP e o banco de dados ainda funcionam por trás do cache. Adicione verificações de TLS e de vencimento de domínio e um heartbeat para o WP-Cron. Nada é instalado no site.

Preciso instalar um plugin de WordPress?

Não. Todas as verificações rodam a partir das sondas do Uptimepage contra o site público, então nada é adicionado ao WordPress e nada para de reportar quando o WordPress quebra. As únicas mudanças que você talvez faça são no servidor, uma linha de cron e uma linha no wp-config.php, se quiser que um heartbeat vigie o WP-Cron.

Verificações a cada 60 segundos deixam o site mais lento?

Não. Uma verificação busca o HTML de uma página, sem imagens, scripts nem estilos, uma vez por minuto a partir de cada região de verificação. Mesmo na página sem cache, onde cada verificação executa PHP, isso fica muito abaixo do tráfego normal de um site em produção. Verificações HTTP não executam JavaScript, então não aparecem no Google Analytics. Um fluxo de navegador executa os scripts da página como um visitante, então as execuções dele podem aparecer lá.

Um plugin de segurança ou firewall bloqueia as verificações. E agora?

Para verificações HTTP, libere as requisições pelo User-Agent: aceite as requisições cujo User-Agent contém uptimepage/. Limite a exceção às URLs que você monitora, porque qualquer um pode enviar esse cabeçalho. Os endereços IP das sondas podem mudar sem aviso, então uma lista de IPs permitidos vai quebrar. Fluxos de navegador enviam outro User-Agent e enviam formulários, então uma regra escrita para verificações HTTP não os cobre. A página do bot, com link abaixo, tem mais detalhes.

Dá para monitorar o checkout do WooCommerce?

Sim, com uma verificação de fluxo de navegador que adiciona um produto ao carrinho e abre o checkout. Ela para antes do pagamento, então não cobra nada e não envia e-mails de pedido.

Um cliente pode ter a própria página de status?

Sim. Uma página de status mostra só os monitores que você coloca nela, então um cliente vê os próprios sites e nada mais, com o logo e as cores dele. O número de páginas de status depende do plano.

Visão geral

Plugin para instalar nenhum, as verificações rodam de fora
Intervalo de verificação a cada 60 s
Canais de alerta e-mail, Slack, Telegram, webhooks e mais
WP-Cron heartbeat a partir de um cron do sistema
Alertas de vencimento certificado SSL e domínio
Preço para começar grátis, sem cartão

Comece em menos de 5 minutos.