Cron do Magento 2 não roda? Faça 9 testes para recuperar as tarefas

Quando o cron do Magento 2 não roda, a loja pode continuar aberta enquanto tarefas importantes se acumulam silenciosamente. E-mails deixam de ser enviados, indexadores permanecem pendentes, regras não entram em vigor no horário esperado e integrações assíncronas atrasam.

Reiniciar serviços ou apagar a tabela cron_schedule pode esconder a causa e ainda eliminar evidências úteis. Antes de alterar o ambiente, registre o horário da falha, os processos afetados e o usuário responsável pelo agendamento. Os nove testes abaixo ajudam a separar problema no sistema operacional, no PHP, no Magento ou em uma tarefa específica.

Cron do Magento 2 não roda: quais sintomas observar?

O cron executa trabalhos agendados por módulos da plataforma e extensões. Uma falha não precisa derrubar toda a loja para causar impacto. Dependendo dos componentes instalados e da configuração, podem surgir sintomas como:

• e-mails transacionais atrasados ou acumulados;
• indexadores configurados por agendamento sem atualização;
• regras de catálogo ou carrinho aplicadas fora do horário;
• feeds, importações e exportações que não avançam;
• filas ou consumidores sem processamento;
• tarefas de extensões fiscais, logísticas ou de ERP paradas;
• grande volume de registros com status pending, missed ou error.

Nem todo atraso significa que o agendador inteiro falhou. Um único job pode apresentar erro enquanto os demais continuam funcionando. O diagnóstico deve identificar se a interrupção é global, limitada a um grupo ou restrita a um código de tarefa.

1. Confirme o usuário e a crontab realmente utilizada

O primeiro teste deve ser feito com o mesmo usuário do sistema operacional usado no deploy e na execução do Magento. Uma ocorrência comum é instalar o agendamento em uma conta e procurar por ele em outra.

whoami
crontab -l

Confirme se existe uma entrada que chama o bin/magento cron:run, se o caminho do projeto é absoluto e se o executável do PHP está correto. Em servidores com múltiplas versões de PHP, chamar apenas php pode executar uma versão diferente daquela usada pela aplicação web.

Não execute bin/magento cron:install sem antes salvar e revisar a crontab existente. O comando altera o agendamento do usuário atual e pode interferir em entradas mantidas manualmente.

2. Verifique o PHP usado pelo cron

Compare o binário informado na crontab com o PHP da linha de comando:

/caminho/do/php -v
/caminho/do/php -m
/caminho/do/php -i | grep memory_limit

Diferenças de versão, extensões ausentes, limites de memória ou arquivos php.ini distintos podem permitir que a vitrine funcione e, ao mesmo tempo, fazer o cron falhar. Execute esses comandos apenas para inspeção; não mude a versão do PHP diretamente em produção sem validar a compatibilidade da plataforma e das extensões.

3. Execute o cron manualmente e preserve a saída

No diretório raiz da aplicação, use o mesmo usuário e o mesmo binário configurados no agendamento:

cd /caminho/da/loja
/caminho/do/php bin/magento cron:run

Registre a saída, o horário e o código de retorno. Se o comando apresentar exceção, falta de classe ou dependência incompatível depois de uma implantação, investigue também um possível conflito no Composer do Magento 2.

O sucesso de uma execução manual não prova que o agendamento do sistema está correto. Ele apenas indica que, naquele contexto, o Magento conseguiu iniciar. Se funcionar manualmente e não automaticamente, concentre a investigação no usuário, ambiente, caminhos, permissões e serviço de cron.

4. Consulte os logs antes de limpar qualquer dado

Examine primeiro os registros da aplicação:

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

Também verifique os logs do serviço de cron e do sistema operacional disponíveis na infraestrutura. Procure pelo horário exato da execução, nome do job, exceções PHP, falta de memória, arquivos inacessíveis e conexões recusadas.

Se a execução devolver uma falha HTTP ou coincidir com indisponibilidade da aplicação, o roteiro de diagnóstico do erro 500 no Magento 2 ajuda a preservar registros e delimitar o componente afetado.

5. Analise a tabela cron_schedule com consultas de leitura

A tabela cron_schedule mostra o histórico e a situação das tarefas. Comece por uma consulta agregada, ajustando o prefixo da tabela caso a instalação utilize um:

SELECT status, COUNT(*) AS total
FROM cron_schedule
GROUP BY status
ORDER BY total DESC;

Depois, procure os registros mais recentes que não terminaram normalmente:

SELECT schedule_id, job_code, status, messages,
       scheduled_at, executed_at, finished_at
FROM cron_schedule
WHERE status IN ('error', 'missed', 'running')
ORDER BY scheduled_at DESC
LIMIT 100;

Muitos itens missed podem apontar ausência ou atraso do executor. Registros antigos em running podem indicar interrupção do processo, mas é preciso confirmar se ainda existe uma execução ativa. Já erros concentrados no mesmo job_code sugerem um problema específico, não necessariamente uma falha global.

Evite truncar ou apagar a tabela como primeiro recurso. Além de destruir o histórico, isso não corrige PHP incompatível, agendamento ausente, bloqueios ou código defeituoso.

6. Procure processos presos ou execuções sobrepostas

Verifique se há processos relacionados ao cron em execução:

pgrep -af 'bin/magento cron:run'
ps aux | grep '[c]ron:run'

Um processo antigo merece investigação, mas não deve ser encerrado apenas por aparecer na lista. Confirme há quanto tempo está ativo, qual job executa e se está consumindo CPU, memória ou aguardando algum recurso externo.

Execuções sobrepostas também podem ocorrer quando o mesmo projeto foi registrado em mais de uma crontab, servidor ou mecanismo de automação. Em ambientes com múltiplos nós, confirme qual componente tem a responsabilidade de disparar as tarefas.

7. Teste permissões e acesso aos diretórios graváveis

O usuário do cron precisa acessar o código e gravar nos diretórios operacionais apropriados. Faça verificações sem aplicar permissões amplas:

ls -ld var generated pub/static pub/media
find var generated -maxdepth 2 ! -user USUARIO_DO_MAGENTO -ls | head

Arquivos criados por root durante um deploy podem bloquear gravações posteriores. Evite usar permissões 777 como correção: isso amplia a exposição e não resolve a origem da propriedade incorreta. Ajustes devem seguir o modelo de usuários e grupos definido para a infraestrutura.

8. Isole o grupo ou job que está falhando

Se alguns trabalhos avançam e outros não, identifique o grupo envolvido. Em ambiente controlado, grupos conhecidos podem ser executados separadamente:

/caminho/do/php bin/magento cron:run --group=default
/caminho/do/php bin/magento cron:run --group=index

Os grupos existentes dependem dos módulos instalados. Não presuma que todos os nomes estarão disponíveis. Relacione o job_code encontrado no banco ao módulo responsável e examine sua configuração, dependências e serviços externos.

Se o problema começou após um deploy, compare código, composer.lock, configuração e artefatos implantados. Uma atualização incompleta pode deixar classes, arquivos gerados ou módulos em estados incompatíveis.

9. Valide a recuperação com uma tarefa observável

Depois de corrigir a causa, não considere o incidente encerrado apenas porque cron:run não exibiu erro. Acompanhe uma tarefa que possa ser verificada do início ao fim.

1. Registre o horário da correção.
2. Observe a criação de novos itens em cron_schedule.
3. Confirme a transição de pending para success.
4. Valide o efeito funcional, como a atualização de um indexador ou o envio controlado de um e-mail.
5. Monitore os logs durante mais de um ciclo.

Também verifique se o volume de tarefas atrasadas não sobrecarrega o servidor durante a retomada. Dependendo do acúmulo, integrações e filas podem precisar de recuperação gradual e acompanhamento de recursos.

O que evitar durante o diagnóstico

• apagar a cron_schedule antes de analisar os registros;
• executar o cron repetidamente em vários terminais;
• encerrar processos sem descobrir o job responsável;
• mudar permissões recursivamente para 777;
• reiniciar todos os serviços e perder a sequência dos eventos;
• testar alterações diretamente em produção sem plano de retorno;
• culpar uma extensão antes de confirmar que apenas os jobs dela falham.

Perguntas frequentes

Com que frequência o cron do Magento 2 deve ser executado?

Normalmente, o disparador do sistema é configurado para executar a cada minuto. Cada job, porém, segue sua própria programação. A frequência real deve ser confirmada na crontab e na configuração dos módulos instalados.

Posso apagar a tabela cron_schedule para destravar o cron?

Não como primeira medida. A exclusão remove evidências e não corrige problemas de PHP, permissões, dependências ou agendamento. Analise os status e as mensagens antes de considerar qualquer limpeza controlada.

Por que o cron funciona manualmente, mas não automaticamente?

As causas mais comuns estão no usuário da crontab, caminho do projeto, binário do PHP, variáveis de ambiente, permissões ou serviço de cron. A execução manual pode usar um contexto diferente do agendador.

Um único job com erro pode parar todas as tarefas?

Nem sempre. O efeito depende do grupo, do módulo e do tipo de falha. Por isso, é importante identificar o job_code e verificar se outros trabalhos continuam mudando para o status success.

Conclusão

Quando o cron do Magento 2 não roda, o caminho mais seguro é preservar logs, confirmar a crontab, comparar o PHP, consultar a cron_schedule e isolar o job afetado. Essa sequência reduz tentativas aleatórias e ajuda a recuperar e-mails, indexadores, filas e integrações sem esconder a causa.

Se as tarefas continuam acumulando ou a falha envolve múltiplos servidores, extensões e serviços externos, uma análise especializada pode reduzir o risco de novas interrupções. A equipe do SuporteMagento.com.br pode auxiliar no diagnóstico e na estabilização do ambiente.