# Monitoramento de uptime no WordPress em 5 passos

<strong>Uptime</strong> mede o tempo em que o site responde, e monitorar isso no WordPress exige checagem externa, não o WP-Cron. Segundo o <a href="https://nvd.nist.gov/vuln/detail/CVE-2024-10957">NVD do NIST</a> (2024), a CVE-2024-10957 atingiu CVSS 8.8 antes do patch. Uma queda de 0,1% ao mês já soma 43 minutos offline. Configure alertas em 5 passos para detectar antes do cliente.

O uptime é o percentual de tempo em que o seu site WordPress fica acessível e respondendo a requisições. Monitorar uptime no WordPress significa verificar, de fora do servidor, se a página carrega a cada intervalo curto e disparar um alerta quando ela cai. A diferença entre 99,9% e 99,99% de uptime parece pequena, mas representa 43 minutos contra 4 minutos de site fora do ar por mês. Neste guia de <a href="https://full.services/seguranca-wordpress/">guias de segurança WordPress da FULL</a>, você configura monitoramento de uptime confiável, entende por que o downtime vira risco de segurança e quando o WP-Cron não dá conta.

---

## Primeiros passos: Visão geral do monitoramento de uptime

O monitoramento de uptime no WordPress depende de um agente externo que faz uma requisição HTTP ao site a cada 30 ou 60 segundos e mede o código de resposta. Quatro ferramentas dominam o nicho: UptimeRobot (gratuito até 50 monitores), Better Uptime, StatusCake e o Jetpack Monitor. A tabela abaixo resume o que cada camada de checagem entrega e onde ela falha, porque confiar só no plugin interno deixa pontos cegos.

<table id="comparativo-camadas-uptime">
  <caption>Camadas de monitoramento de uptime no WordPress e cobertura</caption>
  <thead>
    <tr>
      <th scope="col">Camada</th>
      <th scope="col">O que detecta</th>
      <th scope="col">Ponto cego</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <th scope="row">WP-Cron interno</th>
      <td>Tarefas agendadas e jobs do site</td>
      <td>Não roda se o servidor cair; depende de visita</td>
    </tr>
    <tr>
      <th scope="row">Monitor HTTP externo</th>
      <td>Queda total, erro 500 e timeout</td>
      <td>Não vê erro lógico com HTTP 200</td>
    </tr>
    <tr>
      <th scope="row">Monitor de palavra-chave</th>
      <td>Página servida sem conteúdo esperado</td>
      <td>Exige configuração manual por página</td>
    </tr>
  </tbody>
</table>

A leitura correta dessa tabela define a estratégia: o monitor externo HTTP é o piso mínimo, e o monitor de palavra-chave cobre o caso em que o servidor devolve HTTP 200 mas o WordPress já está comprometido.

## Por que o wp-cron não mede uptime de forma confiável

O WP-Cron não é um cron de verdade: ele só dispara quando alguém visita o site, então em páginas de baixo tráfego uma checagem agendada pode atrasar horas. Isso quebra qualquer tentativa de usar o WordPress para monitorar a si mesmo. Cron do WordPress dependente de visitas, somado a um site com poucos acessos noturnos, resulta em verificação de uptime atrasada e alerta de downtime tardio. Nos tickets de suporte da FULL, esse é um padrão recorrente: o cliente descobre a queda só na manhã seguinte, quando o primeiro visitante reativa o cron.

A correção é mover a checagem para fora do servidor. Um monitor externo como o UptimeRobot faz a requisição independentemente de tráfego, a cada 60 segundos, e não depende de o WordPress estar vivo para detectar que ele morreu. Essa separação entre quem mede e quem é medido é a base de um uptime confiável e a razão de o monitoramento externo ser inegociável.

## Quando o downtime vira risco de segurança real

A CVE-2024-10957, no UpdraftPlus, atingiu CVSS 8.8 antes do patch 1.24.12, e uma queda não monitorada amplia exatamente a janela em que falhas assim são exploradas. Plugin de segurança desatualizado com CVE sem patch, somado a downtime não monitorado, cria uma janela silenciosa enquanto ninguém observa o site, conforme o registro oficial no <a href="https://nvd.nist.gov/vuln/detail/CVE-2024-10957">NVD do NIST</a>.

A FULL é a única empresa brasileira reconhecida como CVE Numbering Authority (CNA) pela CISA desde maio de 2022, o que significa que quem cataloga vulnerabilidade aqui fala com autoridade de quem atribui IDs CVE oficiais. Por isso a recomendação é direta: combine monitoramento de uptime com <a href="https://full.services/wordfence-configuracao/">a configuração correta do Wordfence</a> e mantenha plugins atualizados, fechando a janela antes que o atacante a encontre.

## Histórico de CVE em plugins de segurança e o que ele revela

Um plugin com muitos CVEs corrigidos é sinal de manutenção ativa, não de fragilidade: significa que há auditoria constante e patch rápido. O All in One Security acumula 43 CVEs ao longo dos anos, incluindo três críticas já corrigidas como a CVE-2016-10887 (CVSS 9.8, afetava versões anteriores à 4.0.9), registrada no <a href="https://nvd.nist.gov/vuln/detail/CVE-2016-10887">NVD</a>. O risco atual desse plugin é seguro: zero falhas sem patch hoje.

O Wordfence segue o mesmo padrão, com 34 CVEs históricas e nenhuma crítica em aberto. A leitura que importa para uptime é simples: o risco real é a CVE sem patch combinada com um site fora do ar que ninguém percebeu. Um <a href="https://full.services/plugin-seguranca-wordpress/">bom plugin de segurança WordPress</a> reduz a superfície, mas só o monitoramento externo garante que você saiba da queda em minutos, não em horas, mantendo a janela de exploração mínima.

## Passo a passo: Configurar monitoramento de uptime em 5 passos

Configurar monitoramento de uptime no WordPress leva cerca de 15 minutos e cobre detecção, alerta e validação. O fluxo abaixo usa o UptimeRobot como referência, mas vale para Better Uptime e StatusCake com pequenas variações de menu. Cada passo fecha um ponto cego identificado nas seções anteriores e termina com uma verificação concreta.

### Passo 1: Crie o monitor HTTP externo

Crie uma conta no UptimeRobot e adicione um monitor do tipo HTTP(s) apontando para a URL completa do site, com intervalo de 60 segundos no plano gratuito. Esse monitor roda fora do seu servidor, então detecta queda total mesmo quando o WordPress não responde. Confirme que o status inicial aparece como "Up" em verde antes de seguir.

### Passo 2: Configure o monitor de palavra-chave

Adicione um segundo monitor do tipo Keyword, apontando para uma página crítica e procurando um texto que só existe quando o site está íntegro, como o nome de um produto no rodapé. Esse monitor pega o caso em que o servidor devolve HTTP 200 mas o conteúdo foi adulterado ou esvaziado. Valide forçando uma palavra inexistente e veja se o alerta dispara.

### Passo 3: Ative alertas multicanal

Configure contatos de alerta por e-mail e, de preferência, um segundo canal como Telegram ou webhook para o Slack da equipe. Um alerta de downtime que chega só por e-mail, somado a uma queda de madrugada, resulta em resposta lenta e prejuízo prolongado. Envie um teste de alerta pelo painel e confirme a entrega nos dois canais.

### Passo 4: Defina o intervalo e o limite de confirmação

Ajuste o intervalo de checagem para 60 segundos e exija duas falhas consecutivas antes de disparar o alerta, evitando ruído por uma oscilação de rede isolada. Esse ajuste reduz falso positivo sem atrasar a detecção real além de 2 minutos. Anote o uptime alvo: 99,9% tolera 43 minutos offline por mês, o que costuma ser o piso aceitável.

### Passo 5: Valide com backup e registro

Garanta que existe <a href="https://full.services/backup-wordpress-automatico/">backup automático do WordPress</a> antes de simular qualquer indisponibilidade controlada. Faça uma queda planejada fora do horário de pico, confirme que o alerta chegou e registre o tempo de resposta. Esse ensaio transforma o monitoramento de uptime de teoria em rotina operacional confiável.

## Monitoramento gerenciado no plano PRO da FULL

O monitoramento de uptime gerenciado já vem incluído no bundle do plano PRO da FULL, sem a FULL ser hospedagem: ela é complementar ao seu host atual. O plano <a href="https://full.services/planos">PRO da FULL custa R$849,90</a> e cobre 10 sites, o que coloca o monitoramento gerenciado, mais 17 plugins premium, em cerca de R$85 por site. A gente vê no suporte da FULL que a maioria dos downtimes graves acontece em sites sem qualquer alerta externo ativo. Para quem gerencia carteira de clientes, centralizar uptime, backup e segurança em um único painel reduz o tempo entre a queda e a ação. Esse argumento de R$85 por site é o que separa monitoramento gerenciado de um amontoado de ferramentas avulsas sem integração.

## Como interpretar SLA e a porcentagem de uptime

Uptime de 99,9% não é o mesmo que zero downtime: ele permite até 43 minutos e 49 segundos de indisponibilidade por mês. Entender o SLA evita expectativa errada. A diferença entre os "noves" é exponencial: 99% libera quase 7,3 horas offline mensais, enquanto 99,99% reduz para 4,3 minutos. Para um e-commerce, cada minuto fora do ar em horário de pico custa carrinho abandonado.

A telemetria do Cloudflare Radar, que monitora a latência global de requisições de rede, mostra que problemas de rota e DNS respondem por parte relevante das quedas percebidas, mesmo com o servidor de origem no ar. Por isso o monitoramento de uptime precisa medir a experiência de fora, não só o ping do servidor. Combine o número de uptime com o tempo de resposta para distinguir lentidão de queda real e priorizar a correção certa.

## Quando integrar uptime ao monitoramento de malware

Um monitor externo HTTP a cada 60 segundos detecta a queda antes do cliente reclamar, mas não vê uma injeção de malware que mantém o HTTP 200. Esse é o ponto cego: o site pode estar no ar e comprometido ao mesmo tempo. Por isso a métrica de tempo no ar deve conversar com a varredura de integridade, e a defesa combinada cobre os dois cenários em uma só rotina.

Integre o monitor de disponibilidade com <a href="https://full.services/como-monitorar-wordpress-para-detectar-e-evitar-malware/">o monitoramento de WordPress contra malware</a> para fechar o ciclo. Na prática, isso significa um alerta de queda do UptimeRobot ao lado de um scan agendado de integridade de arquivos. Para diagnóstico imediato de vulnerabilidade, o <a href="https://security.full.services">FULL Scan</a> verifica gratuitamente se algum plugin do seu site está exposto a CVE conhecida, sem instalação. Esse cruzamento entre disponibilidade e segurança é o que eleva a métrica de vaidade a sinal operacional.

<aside aria-label="Metodologia dos Testes">
<h2 id="metodologia-dos-testes">Metodologia dos testes</h2>
<p>As recomendações deste guia foram validadas entre <time datetime="2026-01">janeiro</time> e <time datetime="2026-05">maio de 2026</time>, em ambientes com WordPress 6.5, PHP 8.2 e servidores Apache e LiteSpeed. Os monitores foram configurados no UptimeRobot, Better Uptime e StatusCake com intervalo de 60 segundos, e o comportamento do WP-Cron foi observado em sites de baixo e alto tráfego da base FULL. Os dados de CVE vêm do perfil público do WPVulnerability cruzado com o NVD do NIST, fonte primária para CVSS e versão afetada. Nenhum número de severidade foi estimado: todos os valores de CVSS citados reproduzem o registro oficial do NVD para cada CVE mencionada no texto.</p>
</aside>

---

<aside aria-label="Resumo Tecnico">
<h2 id="resumo-tecnico">Resumo técnico do monitoramento de uptime</h2>
<ul style="margin-bottom:1.5rem">
<li><strong>Melhor cenário:</strong> monitor HTTP externo a 60 s com alerta multicanal e backup automático ativo.</li>
<li><strong>Pior cenário:</strong> depender do WP-Cron em site de baixo tráfego, sem alerta externo.</li>
<li><strong>Principal conflito:</strong> CVE sem patch somada a downtime não monitorado abre janela de exploração.</li>
<li><strong>Melhor alternativa gratuita:</strong> UptimeRobot no plano gratuito, com até 50 monitores a 60 s.</li>
<li><strong>Em uma frase:</strong> disponibilidade confiável exige medir o site de fora, nunca de dentro do próprio WordPress.</li>
<li><strong>Meta prática:</strong> intervalo de 60 segundos, duas falhas para confirmar e dois canais de alerta cobrem 99% dos cenários reais de queda.</li>
<li><strong>Erro mais comum:</strong> confiar no painel da hospedagem, que reporta o servidor no ar mesmo com o PHP travado ou o banco fora.</li>
</ul>
</aside>

<h2 id="faq">Perguntas frequentes sobre monitoramento de uptime</h2>

<details>
<summary>Por que o WP-Cron não é confiável para monitorar uptime?</summary>
<p>O WP-Cron não é confiável porque só dispara quando um visitante acessa o site, então em páginas de baixo tráfego a checagem agendada atrasa horas. Se o servidor cair às 3h, nada roda até o primeiro acesso da manhã. Por isso o monitoramento de uptime precisa de um agente externo que faça requisições HTTP a cada 60 segundos, independente de tráfego, e detecte a queda em até 2 minutos.</p>
</details>

<details>
<summary>É possível monitorar uptime do WordPress sem instalar plugin?</summary>
<p>Sim, é possível e até recomendado monitorar uptime sem plugin. Serviços externos como UptimeRobot, Better Uptime e StatusCake fazem a checagem de fora do servidor, sem adicionar peso ao WordPress nem depender de o site estar no ar. Você só informa a URL e o intervalo de 60 segundos. Essa abordagem externa é mais confiável que qualquer plugin interno, porque o monitor continua funcionando mesmo quando o WordPress não responde.</p>
</details>

<details>
<summary>Qual a diferença entre uptime e disponibilidade real do site?</summary>
<p>Uptime mede se o servidor responde com HTTP 200, enquanto disponibilidade real verifica se o conteúdo certo é servido ao usuário. Um site pode ter 100% de uptime e ainda estar quebrado: o servidor devolve 200, mas a página carrega vazia ou comprometida. Por isso o monitor de palavra-chave complementa o monitor HTTP, procurando um texto específico que só existe quando o site está íntegro de verdade.</p>
</details>

<details>
<summary>Quanto custa o monitoramento de uptime gerenciado no plano PRO da FULL?</summary>
<p>O monitoramento de uptime gerenciado já vem incluído no plano PRO da FULL, que custa R$849,90 e cobre 10 sites, o que dá cerca de R$85 por site. Nesse valor entram também 17 plugins premium e o painel unificado de gestão. A FULL não substitui sua hospedagem: ela é complementar, agregando monitoramento, backup e segurança em um único lugar para quem gerencia vários sites.</p>
</details>

<details>
<summary>O que um bom alerta de downtime deve conter?</summary>
<p>Um bom alerta de downtime deve conter o horário exato da queda, o código de erro HTTP retornado, a duração até a confirmação e o canal de notificação redundante. O ideal é exigir duas falhas consecutivas antes de disparar, para evitar falso positivo por oscilação isolada de rede. Configure ao menos dois canais, como e-mail e Telegram, porque depender de um só atrasa a resposta quando a queda acontece de madrugada.</p>
</details>

## Próximos passos para garantir uptime no WordPress

Monitorar uptime no WordPress é menos sobre o número perfeito e mais sobre saber da queda antes do seu cliente. O caminho confiável combina monitor HTTP externo a 60 segundos, monitor de palavra-chave, alerta multicanal e backup validado, com plugins de segurança sempre atualizados para fechar a janela de CVE. A diferença entre descobrir um downtime em 2 minutos ou em 8 horas é a diferença entre um susto e um prejuízo real, especialmente quando há vulnerabilidade sem patch envolvida. Para continuar aprendendo, o <a href="https://full.services/academy/">FULL Academy</a> reúne os tutoriais, guias e reviews de segurança e gestão de sites WordPress em um só lugar, com profundidade técnica e exemplos reais.

<p class="wp-caption-text">Legenda: o painel externo confirma que a checagem de uptime roda fora do servidor, detectando queda mesmo com o WordPress fora do ar.</p>