Quando um post agendado não publica no horário esperado, o problema pode estar em quatro camadas diferentes: o horário salvo no WordPress, o evento de publicação agendado, o mecanismo que dispara o WP-Cron ou a execução do próprio callback. Separar essas camadas evita soluções aleatórias, como trocar o fuso, instalar outro plugin de cron ou desativar o WP-Cron sem confirmar a causa.
O que acontece quando um post é agendado
O WordPress usa o WP-Cron para tarefas baseadas em tempo. Entre elas está a publicação de posts programados. A documentação oficial explica que o WP-Cron verifica tarefas pendentes quando o site recebe carregamentos de página, em vez de funcionar como um serviço contínuo do sistema operacional. Por isso, um site com pouco tráfego pode executar uma tarefa depois do horário previsto. Veja a documentação do WP-Cron.
Quando um post fica com status futuro, o núcleo agenda o hook publish_future_post. Na hora de executar, o WordPress confirma que o post ainda está com status future e publica o conteúdo. Esse comportamento está documentado em check_and_publish_future_post().
1. Confirme primeiro o fuso e o horário realmente salvo
Antes de culpar o cron, abra Configurações > Geral e confira o fuso do site. A configuração de fuso controla como o WordPress calcula e exibe datas e horários. A própria tela mostra UTC e horário local após salvar, o que ajuda a detectar um deslocamento acidental. Consulte a documentação de Configurações Gerais.
- Confirme se o post continua com status agendado e se a data exibida é a desejada.
- Compare o horário local mostrado pelo WordPress com o horário esperado pelo editor.
- Se o horário salvo estiver incorreto, corrija o agendamento antes de mexer em cron.
Um erro de fuso pode fazer o post parecer atrasado quando, na verdade, o evento foi agendado para outro instante. Se data, hora e status estiverem corretos, siga para o mecanismo de execução.
2. Verifique a Saúde do Site e os loopbacks
Acesse Ferramentas > Saúde do Site. O WordPress informa quando o site não consegue completar uma solicitação de loopback. Loopbacks são chamadas que o WordPress faz para o próprio site e são usados para iniciar eventos agendados. A documentação oficial de loopbacks cita posts agendados como um dos casos afetados.
Se houver falha de loopback, investigue primeiro conflitos de plugin ou tema e depois regras do servidor, firewall, DNS, SSL ou autenticação HTTP. Em produção, prefira reproduzir o problema em staging ou usar uma janela de manutenção antes de desativar componentes.
3. Descubra se o WP-Cron foi desativado
Procure no wp-config.php pela constante DISABLE_WP_CRON. Se ela estiver definida como true, o disparo automático do WP-Cron por visitas fica desativado. Isso é correto somente quando existe outro mecanismo confiável chamando o cron do WordPress.
O erro comum é inverter a ordem: desativar o WP-Cron e só depois tentar configurar o cron externo. Se o agendador do servidor estiver ausente, apontando para a URL errada ou bloqueado, posts futuros podem permanecer pendentes.
4. Com WP-CLI, confirme se o cron consegue iniciar e se o evento existe
Se a hospedagem oferece SSH e WP-CLI, há duas verificações úteis. wp cron test testa o sistema de disparo do WP-Cron. A documentação informa que o comando verifica DISABLE_WP_CRON, avisa sobre ALTERNATE_WP_CRON e tenta iniciar o cron por HTTP. Consulte wp cron test.
Para inspecionar a fila sem alterar o agendamento, use:
wp cron event list --hook=publish_future_post --fields=hook,next_run_gmt,next_run_relative
O comando de listagem é documentado em wp cron event list. Se o hook de publicação futura aparece e está vencido, o agendamento existe e a investigação deve se concentrar no disparo ou na execução. Se ele não aparece para um post que deveria estar agendado, revise o status e o processo que criou o agendamento.
Atenção: comandos que testam ou executam cron podem disparar tarefas vencidas de plugins, e-mail, manutenção ou integrações. Não trate testes de execução como se fossem apenas leitura.
5. Diferencie falha de disparo de falha durante a execução
| Sinal | Interpretação provável | Próxima verificação |
|---|---|---|
| Evento futuro não existe | O post não foi agendado como esperado ou o evento foi removido | Status do post, data e código ou plugin que agenda |
| Evento existe e está vencido | O WP-Cron não foi disparado ou não conseguiu iniciar | Loopback, DISABLE_WP_CRON, cron externo e bloqueios HTTP |
| Cron inicia, mas o post não publica | O callback pode estar falhando durante a execução | Logs PHP, conflitos e erros fatais |
| Só falha em horários sem acesso | O disparo por visita pode ser insuficiente | Cron do servidor para acionamento previsível |
6. Quando usar cron do servidor
Para sites que precisam de maior previsibilidade, a documentação do WordPress recomenda usar o agendador do sistema para chamar wp-cron.php nos intervalos definidos pela operação. Depois que esse disparo externo estiver funcionando, o WP-Cron acionado por visitas pode ser desativado com define( 'DISABLE_WP_CRON', true );. Veja Hooking WP-Cron Into the System Task Scheduler.
Em painéis de hospedagem, essa função pode aparecer como Cron Jobs, Scheduled Tasks ou tarefa agendada. O nome muda, mas o objetivo é o mesmo: executar periodicamente uma chamada que inicializa a fila do WordPress. Não confunda isso com criar uma tarefa separada para cada post.
Ordem segura de mudança:
- Crie a tarefa externa sem desativar o WP-Cron.
- Confirme que ela realmente executa no servidor e que eventos vencidos são processados.
- Monitore pelo menos um ciclo de agendamento compatível com a frequência escolhida.
- Só então defina DISABLE_WP_CRON como true, se houver motivo para evitar o disparo por visitas.
7. Se o cron dispara, procure erros de execução
Quando o evento existe e o mecanismo de cron está ativo, mas a publicação ainda falha, consulte os logs do servidor e, em ambiente de teste, o sistema de depuração do WordPress. A documentação de Debugging in WordPress explica WP_DEBUG e WP_DEBUG_LOG e recomenda staging ou backup antes de mudanças.
Em produção, não deixe mensagens de debug expostas na tela. Logs podem conter caminhos, dados de requisição e outras informações sensíveis. Ative o diagnóstico pelo tempo necessário, colete o erro, corrija a causa e restaure a configuração normal.
WP-Cron ou cron do servidor: o que muda
| Aspecto | WP-Cron acionado por visitas | Cron do servidor chamando WordPress |
|---|---|---|
| Disparo | Depende de uma oportunidade de carregamento do site | Depende do agendador configurado no servidor |
| Precisão | Pode atrasar em períodos sem tráfego | É mais previsível quando a tarefa externa funciona |
| Configuração | Padrão do WordPress | Exige acesso ao painel de hospedagem, SSH ou suporte do provedor |
| Risco operacional | Loopbacks e restrições HTTP podem impedir o disparo | Uma tarefa externa mal configurada pode deixar todo o cron parado se o WP-Cron interno também estiver desativado |
Rollback: como voltar ao comportamento padrão
Se a migração para cron externo causar problemas, restaure o disparo padrão removendo a linha que define DISABLE_WP_CRON como true ou alterando o valor para false. Depois, confirme que o site consegue realizar loopbacks e que novos eventos aparecem na fila.
Não apague eventos cron em massa como primeira tentativa. O WordPress e plugins usam a mesma fila para várias rotinas. Primeiro identifique o hook afetado e a causa do atraso.
Fluxo de diagnóstico em ordem
- Confirme status, data, hora e fuso do post.
- Abra Saúde do Site e procure falha de loopback.
- Verifique se DISABLE_WP_CRON está ativo.
- Se houver WP-CLI, teste o mecanismo e liste publish_future_post.
- Se o evento estiver vencido, corrija o disparo.
- Se o cron estiver disparando, procure erro de execução em logs.
- Se precisar de horário mais previsível, configure cron externo primeiro e só depois avalie desativar o disparo por visitas.
- Se a mudança piorar o cenário, faça rollback e retorne ao WP-Cron padrão.
Essa sequência reduz o risco de confundir atraso por fuso, falta de tráfego, falha de loopback, cron externo quebrado e erro PHP durante a publicação.
