Cron Magento 2 não executa? Faça estes 9 testes antes de acumular tarefas

Quando o cron Magento 2 não executa, a vitrine pode continuar funcionando enquanto tarefas importantes se acumulam silenciosamente. E-mails deixam de sair, regras de preço não são atualizadas, indexadores atrasam e integrações podem parar de processar dados.

Executar bin/magento cron:run manualmente pode aliviar o sintoma, mas não comprova que o agendamento do servidor está correto. Antes de reiniciar serviços ou alterar registros no banco, siga os nove testes abaixo para descobrir onde o fluxo foi interrompido.

Como o cron funciona no Magento 2?

O cron do sistema operacional chama periodicamente a interface de linha de comando do Magento. A aplicação consulta as configurações dos módulos, cria agendamentos na tabela cron_schedule e executa os trabalhos que chegaram ao horário previsto.

Esses trabalhos são organizados em grupos. O grupo default concentra diversas rotinas gerais, enquanto outros componentes podem manter grupos próprios. Extensões de pagamento, ERP, marketplace e logística também podem registrar tarefas personalizadas.

Isso significa que a falha pode ocorrer em diferentes pontos: o sistema operacional não chama o comando, o PHP da linha de comando falha, os trabalhos não são agendados ou uma tarefa específica bloqueia o processamento.

Cron Magento 2 não executa: faça estes 9 testes

1. Delimite quais rotinas estão atrasadas

Não conclua que todo o cron parou apenas porque um e-mail ou uma integração falhou. Registre o primeiro horário conhecido do problema e verifique se outros processos continuam ativos.

• Os e-mails transacionais estão sendo enviados?
• Regras de catálogo e carrinho entram em vigor no horário esperado?
• Os indexadores programados avançam?
• Feeds, importações e exportações são processados?
• A falha atinge apenas uma extensão?

Quando somente uma rotina apresenta atraso, a causa pode estar no código ou na configuração desse módulo. Se vários processos independentes pararam no mesmo horário, investigue primeiro o agendador, o PHP CLI e a infraestrutura.

2. Confira o agendamento do usuário correto

Consulte a crontab do usuário responsável pelo deploy e pela execução do Magento:

crontab -l
sudo crontab -u USUARIO_DA_LOJA -l

Confirme se existe uma entrada chamando o cron do Magento, se o caminho absoluto está correto e se a execução ocorre com a frequência planejada. Também verifique se o serviço de cron do sistema operacional está ativo.

Um erro recorrente é instalar a crontab como root durante uma manutenção, embora os arquivos da loja pertençam a outro usuário. Isso pode gerar arquivos com proprietário inadequado e falhas posteriores de escrita.

3. Valide o PHP utilizado pela linha de comando

O servidor web e o terminal podem usar versões ou configurações diferentes do PHP. Execute os testes com o mesmo binário indicado na crontab:

which php
php -v
php --ini
php -m

Compare a versão, o arquivo php.ini, as extensões carregadas, o limite de memória e o fuso horário. Se a crontab usa um caminho como /usr/bin/php, valide especificamente esse executável.

Uma troca de versão do PHP pode atualizar o PHP-FPM sem alterar corretamente o ambiente CLI, ou fazer o caminho antigo deixar de existir.

4. Execute o cron manualmente com o mesmo usuário

Entre no diretório raiz da aplicação e execute:

php bin/magento cron:run

Faça o teste com o usuário da loja, não apenas como administrador do servidor. Observe a saída e o código de retorno:

echo $?

Se o comando manual funciona, mas a execução automática não, concentre a investigação na crontab, nas variáveis de ambiente e nos caminhos. Se também falha manualmente, examine a mensagem antes de limpar caches ou alterar permissões.

Caso o comando termine com uma exceção genérica, use o roteiro de diagnóstico de erros e logs no Magento 2 para acompanhar a falha nas diferentes camadas.

5. Examine os logs do Magento e do agendador

Verifique os arquivos em var/log, especialmente os registros relacionados ao sistema, exceções e cron. A configuração da crontab também pode redirecionar a saída para um arquivo próprio.

ls -lah var/log
tail -n 200 var/log/cron.log
tail -n 200 var/log/system.log
tail -n 200 var/log/exception.log

Os nomes e a disponibilidade dos arquivos dependem da configuração da loja. Consulte ainda os logs do serviço de cron do sistema operacional para confirmar se o comando foi realmente iniciado no horário esperado.

Procure a primeira exceção, e não apenas mensagens geradas em cascata. Falta de memória, conexão recusada, classe inexistente e erro de permissão exigem correções diferentes.

6. Consulte a fila na tabela cron_schedule

A tabela cron_schedule ajuda a separar falha de agendamento, execução atrasada e erro de uma rotina específica. Faça uma consulta somente leitura e restrinja o volume retornado:

SELECT job_code, status, created_at, scheduled_at,
       executed_at, finished_at
FROM cron_schedule
ORDER BY schedule_id DESC
LIMIT 100;

Interprete os estados com contexto:

• pending: trabalho programado e ainda não iniciado;
• running: execução iniciada, possivelmente ainda ativa;
• success: trabalho concluído;
• missed: tarefa não iniciada dentro da janela esperada;
• error: execução encerrada com falha.

Muitos registros pending antigos podem indicar ausência de consumidores do cron ou processamento insuficiente. Já erros concentrados em um único job_code apontam para uma rotina específica. Não atualize os estados diretamente no banco para “destravar” a fila: isso elimina evidências e pode permitir execuções duplicadas.

7. Verifique processos longos e concorrência

Uma tarefa lenta pode ocupar recursos, manter bloqueios ou atrasar trabalhos do mesmo grupo. Confira processos ativos e sua duração:

ps aux | grep '[b]in/magento cron:run'
ps aux | grep '[p]hp'

Antes de encerrar qualquer processo, confirme o horário de início, o consumo de recursos e a operação executada. Um processo ativo não está necessariamente travado; ele pode estar importando um catálogo grande ou aguardando uma API externa.

Se os atrasos coincidem com indexação, consulte também o estado dos indexadores. Corrigir apenas o cron não resolverá uma rotina bloqueada por banco, busca ou código personalizado.

8. Teste dependências externas da rotina afetada

O cron pode ser iniciado corretamente e falhar ao acessar banco de dados, Redis, serviço de busca, servidor SMTP, ERP ou gateway. Identifique qual dependência aparece na primeira exceção e teste a conectividade a partir do mesmo servidor e usuário.

Se a falha menciona conexão, memória ou sessões no Redis, siga estes testes de Redis no Magento 2 antes de reiniciar ou limpar a instância. Para tarefas que publicam mensagens em filas, verifique também consumidores e broker; o planejamento dessas camadas é explicado no guia sobre filas do Magento com RabbitMQ e ActiveMQ Artemis.

9. Revise permissões e mudanças recentes

Compare o início da falha com deploys, atualizações de PHP, troca de usuário, restauração de backup ou mudanças de diretório. O usuário do cron precisa ler o código e gravar nos diretórios operacionais apropriados, sem recorrer indiscriminadamente a permissões abertas.

id
pwd
ls -ld var generated pub/static pub/media
find var generated -maxdepth 2 ! -user USUARIO_DA_LOJA -ls

O último comando deve ser ajustado à estrutura e à política de usuários do servidor. Não execute chmod -R 777: além de ampliar a exposição da aplicação, isso não corrige proprietário incorreto, ACL, montagem somente leitura ou restrições do ambiente.

Como validar a correção sem duplicar tarefas

Depois de corrigir a causa, acompanhe pelo menos dois ciclos completos do agendador. Confirme que novos registros são criados, passam por pending e terminam em success dentro do intervalo esperado.

Valide também o efeito funcional: um e-mail de teste foi enviado, o índice avançou ou a integração processou um registro controlado? Evite disparar repetidamente o cron em paralelo, pois uma rotina sem proteção adequada pode executar a mesma operação mais de uma vez.

Documente o usuário, o binário do PHP, a entrada da crontab, os arquivos de log e os alertas aplicáveis. Monitorar a idade do último trabalho concluído é mais útil do que verificar apenas se o serviço de cron está ativo.

Perguntas frequentes

Posso executar bin/magento cron:run manualmente?

Sim, desde que o comando seja executado no diretório correto e com o usuário da aplicação. Ele é útil para diagnóstico, mas não substitui a correção do agendamento automático.

É seguro apagar a tabela cron_schedule?

Não como primeira medida. A tabela contém evidências importantes sobre tarefas pendentes, perdidas e com erro. Uma limpeza sem análise pode ocultar a causa e interferir em trabalhos ainda necessários.

Por que o cron funciona no terminal, mas não na crontab?

As causas mais comuns são usuário diferente, caminho incorreto, PHP CLI distinto, diretório de trabalho inadequado e ausência de variáveis de ambiente disponíveis na sessão interativa.

Um único módulo pode travar o cron do Magento?

Uma rotina personalizada lenta ou defeituosa pode atrasar trabalhos do mesmo grupo e consumir recursos. A tabela cron_schedule, os logs e a lista de processos ajudam a identificar o job_code responsável.

Conclusão

Quando o cron Magento 2 não executa, a correção segura começa pela delimitação das tarefas afetadas e segue pela crontab, PHP CLI, logs, tabela cron_schedule, processos e dependências externas. Esse método preserva evidências e reduz o risco de duplicar rotinas comerciais.

Se pedidos, e-mails, integrações ou indexadores continuam acumulados, uma análise técnica do ambiente pode localizar o bloqueio e restaurar o processamento com controle. A equipe do SuporteMagento.com.br pode apoiar o diagnóstico e a correção da operação.