Quando o WP-Cron não funciona, backups, publicações agendadas, e-mails e rotinas de plugins podem atrasar. A causa mais comum é o próprio modelo do WordPress: ele verifica tarefas quando recebe acessos, em vez de manter um serviço contínuo. O diagnóstico correto começa pela lista de eventos, passa por loopback, cache e erros PHP e, em sites importantes, termina com um agendador real chamando o WordPress em intervalos regulares.
Conteúdo revisado em 21/09/2026. Faça backup e teste comandos no ambiente de staging antes de alterar cron ou wp-config.php.
O que é WP-Cron
WP-Cron é o sistema de tarefas agendadas do WordPress. O núcleo o utiliza para publicar posts futuros, verificar atualizações e executar manutenções. Plugins o usam para enviar filas, gerar relatórios, renovar integrações e remover dados temporários. Conforme o manual oficial de Cron do WordPress, a verificação ocorre em carregamentos de página. Por isso, o horário representa “executar a partir deste momento”, e não uma garantia de precisão ao segundo.
Em um blog com pouco tráfego, uma tarefa das 10h pode rodar apenas quando alguém acessa o site às 11h. Em um site muito movimentado, tentativas de disparo podem aumentar requisições internas. A solução é entender se existe atraso normal, bloqueio ou falha dentro da tarefa.
Sintomas de WP-Cron com problema
- post programado aparece como “agendamento perdido”;
- backup automático não é criado no horário;
- e-mails ou pedidos permanecem em processamento;
- feeds, relatórios e limpezas não são atualizados;
- o painel mostra eventos atrasados ou erro de loopback;
- o arquivo
wp-cron.phprecebe muitas chamadas ou nenhuma; - uma fila volta a travar mesmo após execução manual.
Um evento atrasado não prova que o sistema inteiro falhou. Pode haver uma função específica com erro, um plugin que registrou a tarefa incorretamente ou uma rotina longa que excedeu memória e tempo.
Como listar os eventos agendados
Com WP-CLI instalado, liste os eventos:
wp cron event list
wp cron event list --fields=hook,next_run_gmt,next_run_relative,recurrence
wp cron test
Os comandos oficiais estão documentados no WP-CLI Cron. Procure eventos cuja próxima execução ficou no passado, nomes repetidos em excesso ou hooks de plugins removidos. Não apague um evento desconhecido antes de identificar seu responsável.
Sem SSH, um plugin de inspeção pode mostrar a fila no painel. Instale apenas durante o diagnóstico, restrinja o acesso administrativo e remova ferramentas que não terão uso contínuo.
Etapa 1: confirme o comportamento básico
- Agende um post de teste para alguns minutos no futuro.
- Acesse o site em uma janela anônima depois do horário.
- Confira se o post foi publicado e se o horário do WordPress está correto.
- Execute
wp cron teste registre a resposta. - Consulte a ferramenta Saúde do site em Ferramentas.
Em Configurações > Geral, use a cidade correspondente quando disponível ou confira o deslocamento UTC. Um fuso incorreto parece falha de cron, mas o evento apenas foi agendado para outro instante.
Etapa 2: verifique se o cron foi desativado
Abra wp-config.php e procure:
define( 'DISABLE_WP_CRON', true );
Essa configuração é correta quando existe um cron real no painel ou servidor. Se ninguém chama wp-cron.php, todas as tarefas param. Não troque para false por impulso: primeiro confirme se há uma entrada externa e quem a administra.
Também procure regras de segurança que bloqueiem wp-cron.php, autenticação HTTP no site, firewall e plugins que desativam requisições internas. Um staging protegido por senha precisa de configuração especial para executar loopback.
Etapa 3: teste loopback e resolução do domínio
O WordPress normalmente inicia o cron fazendo uma requisição HTTP para si mesmo. Falhas de DNS, certificado, redirecionamento, proxy ou firewall podem impedir essa volta. Verifique se a URL do site abre no próprio servidor e retorna resposta válida.
Com acesso ao terminal, um teste básico é:
curl -I https://www.exemplo.com.br/wp-cron.php?doing_wp_cron
Uma resposta vazia com código HTTP de sucesso pode ser normal. O que importa é não haver timeout, erro de certificado, ciclo de redirecionamento, 403 ou 500. Analise o log de acesso para confirmar a chamada e o log de erros para descobrir falhas internas.
Etapa 4: ative logs sem exibir erros
Em staging, configure temporariamente:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );
A documentação de depuração do WordPress recomenda usar essas ferramentas em ambientes de teste. Execute o evento novamente e leia wp-content/debug.log junto com o log do PHP. Remova ou desative o debug depois; logs podem conter caminhos e informações sensíveis.
Como executar uma tarefa manualmente
Identifique o hook e faça primeiro uma simulação operacional: confirme backup, recursos e efeito esperado. Depois execute:
wp cron event run nome_do_hook
wp cron event run --due-now
--due-now roda todos os eventos vencidos e pode iniciar uma carga grande. Em loja ou site com filas, comece pelo hook problemático. Se ele falhar manualmente, o problema está na função, dependência ou recurso, e não no disparador do cron.
Como configurar um cron real no cPanel
O guia oficial para usar o agendador do sistema orienta chamar o cron externamente e desativar o disparo em visitas. No cPanel, abra Trabalhos Cron e prefira o PHP CLI quando o caminho do WordPress e a versão do PHP estiverem confirmados:
*/5 * * * * cd /home/usuario/public_html && /usr/local/bin/wp cron event run --due-now --quiet
Quando WP-CLI não está disponível, outra opção é solicitar a URL localmente:
*/5 * * * * /usr/bin/curl --silent --show-error --max-time 60 'https://www.exemplo.com.br/wp-cron.php?doing_wp_cron' >/dev/null
Os caminhos variam por servidor. No cPanel com múltiplas versões PHP, um comando genérico pode usar uma versão diferente do site. Peça à hospedagem o binário correto ou use a ferramenta Cron Jobs do painel com os caminhos exibidos pela conta.
Quando definir DISABLE_WP_CRON
Depois de confirmar que o cron real executa corretamente, adicione antes da linha final do wp-config.php:
define( 'DISABLE_WP_CRON', true );
Essa combinação evita tentativas em cada tráfego e cria um intervalo previsível. Cinco minutos atende muitos sites. Filas urgentes podem exigir um minuto; rotinas pesadas podem usar quinze minutos ou horários específicos. O intervalo deve respeitar a necessidade e os recursos.
Como evitar execuções duplicadas
Não mantenha vários serviços externos, cron do sistema e disparo por visita sem entender como a tarefa bloqueia concorrência. O WordPress usa travas temporárias, mas plugins podem implementar filas próprias. Duas execuções longas ao mesmo tempo podem duplicar e-mails, elevar CPU ou competir pelas mesmas linhas do banco.
Use um único mecanismo principal, mantenha o intervalo maior que o tempo comum de execução e monitore processos. Se uma tarefa leva mais de cinco minutos, investigar a causa é melhor que iniciar uma nova cópia a cada cinco minutos.
Cache, segurança e CDN
Cache de página normalmente não impede o cron, mas regras agressivas podem evitar que o PHP seja acionado. WAF e CDN podem desafiar ou bloquear chamadas a wp-cron.php. Libere a rota apenas da forma necessária, sem expor painel ou criar uma regra ampla. Se o cron roda por CLI, ele evita parte dessas camadas e facilita registrar o código de saída.
Checklist de diagnóstico do WP-Cron
- Confira fuso e horário do evento.
- Liste hooks e tarefas vencidas.
- Veja se
DISABLE_WP_CRONestá ativo. - Confirme o agendador externo correspondente.
- Teste loopback, DNS, TLS e redirecionamentos.
- Execute somente o hook afetado e leia os logs.
- Verifique memória, tempo máximo e processos simultâneos.
- Revise cache, WAF, CDN e autenticação.
- Corrija a causa no plugin ou integração.
- Monitore a próxima execução automática.
Perguntas frequentes
WP-Cron precisa de acesso de visitantes?
No modo padrão, uma visita dispara a verificação. Com um cron real chamando o WordPress, as tarefas podem rodar mesmo sem tráfego.
Posso chamar wp-cron.php a cada minuto?
Pode, mas isso raramente é necessário. Avalie o menor intervalo exigido e o tempo das tarefas. Um intervalo curto não corrige um hook que falha.
“Agendamento perdido” significa que o post foi apagado?
Não. O post permanece com status futuro e pode ser publicado quando o cron voltar a executar. Investigue rapidamente para evitar outros atrasos.
Executar todos os eventos é seguro?
Depende do volume. Em um site com fila acumulada, rodar tudo pode gerar pico de processamento. Faça backup, identifique hooks e acompanhe logs e recursos.
Conclusão
Para corrigir WP-Cron, separe falha de disparo de falha da tarefa. Liste eventos, confira horário, execute o hook afetado e use logs para identificar o ponto exato. Depois revise loopback, segurança e recursos.
Em um site profissional, configurar o cron real e desativar o disparo por visitas oferece previsibilidade. Acompanhe o resultado: agendar o comando é apenas metade do trabalho; ele precisa rodar com a versão correta do PHP, concluir sem erro e processar a fila no tempo esperado.