Tarefas agendadas do WordPress

Um Cron é um agendador de tarefas em sistemas operacionais tipo Unix (Linux, macOS) que executa comandos ou scripts automaticamente em horários ou intervalos definidos. No WordPress, o wp-cron.php é o mecanismo interno de tarefas agendadas, conhecido como WP-Cron. No entanto, ele é considerado um pseudo-cron, pois não é ativado em horários fixos, e sim com requisições.

Pensando em uma analogia simples para entender como ele funciona, imagine que a requisição é uma pessoa entrando na loja. O WP-Cron é o faxineiro: ele só trabalha quando alguém entra e só depois que a pessoa sai. Se ninguém entra, não tem faxina. Se entram muitos ao mesmo tempo, o faxineiro atrapalha a saída.

Sua função é a de executar tarefas automáticas do site, como:

• Publicação de posts agendados
• Verificação de atualizações de plugins e temas
• Limpeza de rascunhos automáticos
• Envio de notificações por e-mail
• Execução de rotinas criadas por plugins (backups, estatísticas, cache, etc.)

Os horários ficam armazenados no banco de dados, não nesse arquivo. Por padrão, cada vez que alguém acessa o site, o WordPress verifica “Existe alguma tarefa agendada que já passou da hora?”. Se existir, ele faz uma requisição HTTP em segundo plano para wp-cron.php. Exemplos de requisições:

• Um visitante abre https://seusite.com/
• Um bot do Google acessa uma página
• Você acessa /wp-admin/
• Um navegador pede um CSS, JS ou imagem
• Um plugin faz wp_remote_get() para uma URL do próprio site

Cada uma dessas ações gera uma requisição HTTP que passa pelo PHP. Durante qualquer requisição que carregue o WordPress, o core faz o seguinte:

1. O WordPress processa a página normalmente
2. Antes de encerrar a execução do PHP, ele dispara o hook: do_action(‘shutdown’);
3. Nesse hook, o WordPress chama internamente: _wp_cron();
4. O _wp_cron() verifica “Existe algum evento agendado para agora ou atrasado?”
5. Se existir, ele tenta criar o lock _transient_doing_cron e dispara o wp-cron.php em background

Isso tudo acontece depois que a resposta já foi enviada ao navegador. Internamente, o arquivo wp-cron.php:

1. Carrega o ambiente do WordPress
2. Inicializa o core, plugins e temas
3. Verifica se já existe um cron em execução
4. Usa um lock (doing_cron) para evitar execuções simultâneas
5. Busca no banco de dados os eventos vencidos
6. Executa cada evento agendado
7. Chamando os hooks registrados (do_action)
8. Libera o lock ao final
9. Finaliza com die();

Note que não tem “echo” nem “print”, ou seja, se a saída for vazia, isso significa uma execução normal.

Como trocar o pseudo-cron pelo cron do servidor

Desativar o pseudo-cron do WordPress (WP-Cron) e delegar a execução das tarefas agendadas a um cron real no servidor é uma prática importante porque o WP-Cron depende de acessos HTTP para ser disparado e é executado no final das requisições, compartilhando a mesma execução de PHP e a mesma conexão com o banco de dados da página solicitada. Em ambientes modernos, com cache agressivo, CDN e alto volume de acessos, isso pode causar atrasos na execução das tarefas, picos de uso de CPU, conflitos com mecanismos de cache e até erros de banco de dados, como problemas de sincronização de comandos.

Ao utilizar o cron do sistema operacional, as tarefas passam a ser executadas de forma previsível, independente de visitas ao site, em um contexto isolado via PHP CLI, reduzindo o acoplamento com requisições de usuários, aumentando a confiabilidade do agendamento e melhorando a estabilidade e o desempenho geral do WordPress.

O primeiro passo é desativar o pseudo-cron. Para isso, abra o arquivo wp-config.php e escreva o seguinte comando antes do comentário “Isto é tudo, pode parar de editar”:

define('DISABLE_WP_CRON', true);

Se ele não estava aparecendo no arquivo original, isso significa que o cron estava ativado.

O outro passo é editar o crontab do sistema. No caso desse serviço de hospedagem, existe um auxílio de configuração do cron na interface gráfica no painel de controle:

Para entender melhor (e gerar o comando manualmente), veja mais no post Agendamento de tarefas no crontab. O comando final gerado fica assim, por exemplo:

*/5 * * * * /usr/bin/php /home/u12345678/public_html/wp-cron.php > /dev/null 2>&1

“> /dev/null 2>&1” não é obrigatório, mas é uma boa prática em produção para manter o sistema limpo e silencioso. Quando você quer observar o comportamento, basta redirecionar para um arquivo de log temporário.

Como saber exatamente o que está agendado?

O WP-CLI (WordPress Command Line Interface) é uma ferramenta de linha de comando que permite administrar e interagir com o WordPress diretamente pelo terminal do servidor, sem depender do painel administrativo ou de requisições HTTP. Ele possibilita executar comandos de manutenção, atualizar plugins e temas, inspecionar o banco de dados e, especialmente, listar, executar e depurar as tarefas agendadas (WP-Cron) de forma direta e confiável. Sua importância no gerenciamento do agendamento de tarefas está no fato de permitir visualizar eventos, recorrências, próximos horários de execução e execuções atrasadas em tempo real, facilitando o diagnóstico de problemas de cron, validando a correta execução via cron do sistema e evitando dependência do pseudo-cron acionado por acessos ao site.

Para sua utilização, você deverá permitir o acesso SSH no servidor e usar o terminal Linux para acessá-lo. Então, siga para a pasta raiz do WordPress onde fica o arquivo wp-config.php (ex: cd /var/www/seusite ou /home/u12345678/public_html). Para ver se está no local certo e se o programa está instalado, execute o seguinte comando:

wp --info

Se aparecer algo como “WP-CLI version: 2.x.x”, o WP-CLI está disponível.

Finalmente, você pode verificar a lista de tarefas através do comando:

wp cron event list

A tabela a seguir exibe um exemplo de lista de tarefas:

Entenda um pouco sobre as tarefas relacionadas a cada plugin:

• Broken Link Checker (blc_cron_check_links, blc_cron_database_maintenance): verifica periodicamente links quebrados no site e executa manutenção diária no banco de dados do plugin.
• LiteSpeed Cache (litespeed_task_*): executa tarefas internas de otimização como geração e limpeza de cache, otimização de imagens, sincronização de usuários convidados e processamento de CSS/JS.
• WPMU DEV (wpmudev_scheduled_jobs): roda tarefas agendadas do conjunto de plugins da WPMU DEV, como verificações de status, relatórios e rotinas de manutenção.
• WP Privacy (wp_privacy_delete_old_export_files): remove arquivos antigos de exportação de dados pessoais, conforme exigências de privacidade e LGPD/GDPR.
• WordPress Core – Atualizações (wp_update_plugins, wp_update_themes, wp_update_user_counts, wp_version_check): verifica novas versões do WordPress, plugins e temas, além de atualizar contadores de usuários.
• WordPress Core – Sistema (delete_expired_transients, get_transient_features): limpa dados temporários expirados (transients) e atualiza informações internas usadas para desempenho e compatibilidade.
• WordPress Core – Conteúdo (publish_future_post): publica automaticamente posts agendados para datas futuras.
• WordPress Core – Limpeza (wp_scheduled_auto_draft_delete, wp_scheduled_delete, wp_delete_temp_updater_backups): remove rascunhos automáticos, dados obsoletos e backups temporários gerados por atualizações.
• WordPress Core – Saúde do Site (wp_site_health_scheduled_check): executa verificações periódicas de integridade, segurança e desempenho do site.
• Akismet (akismet_scheduled_delete): remove registros antigos de spam e dados temporários relacionados à filtragem de comentários.
• Google Site Kit (googlesitekit_cron_update_remote_features, googlesitekit_cron_synchronize_adsense_linked_data): sincroniza dados remotos do Google (Analytics, Search Console, AdSense) e atualiza funcionalidades disponíveis.
• MonsterInsights (monsterinsights_usage_tracking_cron): envia estatísticas de uso anônimas e executa tarefas relacionadas ao rastreamento do Google Analytics.
• Recovery Mode (recovery_mode_clean_expired_keys): remove chaves expiradas usadas no modo de recuperação do WordPress após falhas críticas.
• Simple Sitemap / SEO (sm_ping_daily): notifica diariamente mecanismos de busca sobre atualizações no sitemap do site.
• WP Asset CleanUp (wpacu_daily_scheduled_events): executa rotinas diárias para otimização e descarregamento seletivo de CSS e JavaScript.

O comando a seguir executa todos os eventos de cron que já estão vencidos (independente de requisição):

wp cron event run --due-now

Em um caso ideal, deve aparecer uma mensagem parecida com “Success: Executed 5 of 5 scheduled cron events.” Isso indica que o banco está OK, assim como os eventos. Em um caso com warnings, deve aparecer algo como “Warning: Event wp_version_check is not due”, e com erro, “Error: There has been a critical error on this website” ou erro de plugin específico “Error: Call to undefined function…”

Esse controle também pode ser feito através de plugins, como o WP Crontrol ou o Advanced Cron Manager. Essas ferramentas mostram todas as tarefas, horários, intervalos e plugins responsáveis.

Monitoramento de erros

A seguir estão listados os principais métodos de debug e logs de servidor utilizados em WordPress, com uma breve descrição do que cada um captura:

• WP_DEBUG / WP_DEBUG_LOG: registra avisos, notices, mensagens deprecatadas e erros fatais do PHP gerados durante a execução do WordPress, permitindo identificar problemas de código.
• debug.log (wp-content): arquivo onde o WordPress grava as mensagens de debug quando o WP_DEBUG_LOG está ativo, centralizando erros e avisos do núcleo, temas e plugins.
• php_error.log: captura erros fatais do PHP, estouros de memória, timeouts e falhas que ocorrem antes ou fora do controle direto do WordPress.
• error_log_dominio_com_br (diretório .logs): registra erros de execução do servidor web (Apache/Nginx), falhas de rewrite, problemas de comunicação com o PHP e situações de sobrecarga momentânea.
• logs de cron (cronjob_*.log): armazenam a saída e possíveis erros de tarefas agendadas executadas via cron real, ajudando a identificar jobs que consomem muito processamento.
• access.log: registra todas as requisições HTTP recebidas pelo servidor, sendo fundamental para identificar picos de acesso, bursts de requisições, bots, scans e endpoints que geram alto consumo de CPU.

Obs.: Para ativar o debug e direcionar a saída para o arquivo “debug.log”, além de usar a flag true para ‘WP_DEBUG’, inclua a seguinte configuração no arquivo wp-config.php:

define('WP_DEBUG', true);
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

O WordPress escreve mensagens, o PHP registra, e o host armazena nesse arquivo de erros do servidor (error_log_dominio_com_br). Veja três exemplos de clássicos sintomas do WP-Cron rodando via requisição HTTP.

1. “WordPress database error Commands out of sync; you can’t run this command now”

Nele, o WP-Cron tentou criar/atualizar o lock _transient_doing_cron. Isso aconteceu no hook shutdown, mas a conexão MySQL ainda estava ocupada. Resultado: erro de sincronização.

2. “Erro de evento de reagendamento do cron para o gancho: blc_cron_check_links, código de erro: could_not_set, mensagem de erro: Não foi possível salvar a lista de evento do cron”

O evento executou, mas ao tentar reagendar (salvar o próximo horário), o WordPress não conseguiu atualizar o banco. Isso acontece quando o WP-Cron roda em contexto instável, o banco está ocupado e/ou o Lock não pôde ser salvo. O plugin em questão é o Broken Link Checker.

3. “Erro de evento de reagendamento do cron para o gancho: litespeed_task_imgoptm_req, código de erro: could_not_set, mensagem de erro: Não foi possível salvar a lista de evento do cron”

Aqui temos um evento de otimização de imagens do LiteSpeed. Ele apresenta frequência alta e falha ao salvar o próximo agendamento. Sua causa típica é o WP-Cron rodando no shutdown, cache interferindo e concorrência de requisições.

Posts relacionados:

Tópicos de Web Design e links úteis Monetização de sites Google AdSense Como escolher seu sistema de gerenciamento de conteúdo