Cron do Magento 2 não roda? 9 verificações para encontrar a falha

O cron do Magento 2 não roda e tarefas importantes começaram a atrasar? E-mails de venda, atualização de regras de preço, indexadores, rotinas de estoque, feeds e integrações podem depender desse agendamento. O problema é que nem sempre existe uma mensagem visível no painel administrativo.

Antes de reinstalar módulos, limpar todos os caches ou reiniciar serviços indiscriminadamente, vale descobrir se a falha está no agendador do servidor, no usuário de execução, no PHP, no banco de dados ou em um job específico. As verificações abaixo ajudam a fazer esse diagnóstico de forma organizada.

Como saber se o cron do Magento 2 não roda?

O primeiro passo é separar uma falha geral de um atraso isolado. Quando todo o cron deixa de funcionar, vários processos costumam apresentar sintomas ao mesmo tempo. Quando apenas uma tarefa falha, outras rotinas continuam sendo concluídas normalmente.

Alguns sinais comuns são:

• e-mails transacionais enviados com atraso ou não enviados;
• regras de preço que não entram ou não saem de vigor no horário esperado;
• indexadores acumulados no estado pendente;
• importações, exportações ou integrações que param de avançar;
• pedidos que demoram para chegar ao ERP ou a serviços externos;
• muitos registros com status pending, missed ou error na tabela cron_schedule.

Um indexador pendente nem sempre significa cron quebrado. Ele também pode estar bloqueado, processando um volume elevado ou falhando por outro motivo. Se o sintoma estiver limitado ao catálogo, consulte também o checklist para quando um produto não aparece no Magento 2.

1. Confirme se existe uma entrada no crontab correto

O agendador precisa estar instalado no crontab do usuário que opera os arquivos do Magento. No terminal, acesse o projeto com esse usuário e execute:

crontab -l

Verifique se existem entradas relacionadas ao caminho real da instalação. Um erro frequente é consultar o crontab do usuário atual enquanto o agendamento foi criado em outra conta. Também pode acontecer de o cron ter sido instalado como root, o que favorece arquivos com propriedade incorreta e problemas posteriores no deploy.

Se não houver configuração, o Magento oferece um comando para instalá-la:

php bin/magento cron:install

Execute-o somente com o proprietário apropriado do projeto e confirme o resultado novamente com crontab -l. Em hospedagens gerenciadas, contêineres ou plataformas em nuvem, o agendamento pode ser controlado fora do crontab tradicional. Nesses casos, confira o mecanismo definido pela infraestrutura antes de criar uma execução duplicada.

2. Teste o comando manualmente com o mesmo usuário

Executar o cron manualmente ajuda a revelar erros que ficam ocultos quando o processo é iniciado pelo sistema:

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

Não faça o teste como root. Use o mesmo usuário configurado no agendador e, em produção, prefira um horário de menor movimento. Algumas tarefas podem consumir CPU, memória, banco de dados ou serviços externos.

Uma execução pode apenas agendar determinados jobs para o próximo ciclo. Quando necessário, aguarde o intervalo normal e faça uma segunda verificação, em vez de iniciar o comando repetidamente. Se aparecer uma exceção, registre o horário e preserve a mensagem completa antes de tentar corrigi-la.

3. Compare o PHP do terminal com o PHP esperado pela loja

O site pode utilizar uma versão do PHP-FPM enquanto o cron chama outra versão no terminal. Extensões, limites de memória, arquivo php.ini e variáveis de ambiente também podem ser diferentes.

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

Compare essas informações com a configuração usada pela aplicação. Se a entrada do crontab aponta simplesmente para php, confirme qual binário é resolvido naquele contexto. O cron do sistema normalmente trabalha com um ambiente mais limitado do que uma sessão interativa no terminal.

Esse cuidado é especialmente importante depois de trocar a versão do PHP ou atualizar dependências. Se a manutenção também estiver bloqueada por pacotes incompatíveis, veja como diagnosticar um erro no Composer do Magento.

4. Consulte os registros da tabela cron_schedule

A tabela cron_schedule mostra quais tarefas foram agendadas e como terminaram. Uma consulta somente de leitura pode oferecer uma visão inicial:

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

Os principais estados devem ser interpretados em conjunto com os horários:

• pending: a tarefa foi agendada, mas ainda não começou;
• running: o processamento foi iniciado;
• success: a execução terminou normalmente;
• missed: a janela prevista passou sem execução;
• error: o job iniciou, mas encontrou uma falha.

Muitos registros missed podem indicar cron interrompido, servidor sobrecarregado ou intervalo incompatível com a duração das tarefas. Um único job_code acumulando erros sugere problema localizado em um módulo ou integração.

Evite apagar a tabela como primeira tentativa. Além de eliminar evidências importantes, isso não corrige a causa que impediu o processamento.

5. Leia os logs do Magento e do agendador do servidor

Consulte primeiro os arquivos disponíveis em var/log, principalmente:

• var/log/cron.log;
• var/log/system.log;
• var/log/exception.log;
• logs específicos criados por módulos e integrações.

Também verifique o registro do serviço de cron da distribuição Linux. Dependendo da infraestrutura, as mensagens podem estar no journal do sistema ou em arquivos como /var/log/cron e /var/log/syslog. Procure pelo horário exato da falha e pelo usuário responsável pela execução.

Erros de classe inexistente, conexão recusada, falta de memória ou dependência indisponível exigem correções diferentes. Se a mesma exceção também derrubar páginas da loja, o diagnóstico de erro 500 no Magento 2 ajuda a investigar as camadas envolvidas.

6. Verifique permissões, disco e diretórios graváveis

O cron pode iniciar e falhar ao tentar gravar em var, generated, pub/static ou outros diretórios usados pelo projeto. Isso costuma ocorrer depois de deploys executados por usuários diferentes.

df -h
df -i
ls -ld var generated pub/static

Além do espaço em disco, confira os inodes. Um servidor pode ter capacidade disponível em gigabytes e ainda assim não conseguir criar arquivos por esgotamento de inodes.

Não aplique permissões abertas, como chmod -R 777. Corrija proprietário, grupo e modelo de implantação conforme a arquitetura do ambiente.

7. Identifique jobs longos, travados ou concorrentes

Uma tarefa demorada pode ocupar recursos e fazer outras perderem sua janela de execução. Procure processos ativos e compare o tempo de execução com o comportamento normal da operação:

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

Antes de encerrar um processo, confirme o que ele está executando. Interromper uma importação, atualização de estoque ou integração no meio pode deixar dados incompletos. Jobs marcados como running por muito tempo também devem ser comparados com processos realmente ativos, pois uma execução encerrada abruptamente pode ter deixado um registro antigo no banco.

8. Isole o grupo ou módulo que está falhando

O Magento organiza tarefas em grupos. Em um diagnóstico controlado, é possível testar um grupo específico:

php bin/magento cron:run --group=default

Use o nome de um grupo que realmente exista no projeto. Extensões podem registrar grupos e jobs próprios em arquivos crontab.xml. Se o problema começou após instalar ou atualizar um módulo, procure o respectivo job_code nos registros e confirme se sua classe, configuração e dependências estão disponíveis.

Desabilitar uma extensão diretamente em produção pode afetar checkout, pagamentos ou integrações. Reproduza a falha em staging quando a correção exigir mudança de código.

9. Confira banco de dados, cache e serviços externos

O cron pode estar configurado corretamente e ainda falhar porque depende de banco de dados, cache, mecanismo de busca, filas ou APIs externas. Timeouts e conexões recusadas nos logs ajudam a diferenciar uma falha do agendador de uma indisponibilidade em outro serviço.

Também verifique se houve reinício do servidor, alteração de credenciais, mudança de firewall ou deploy próximo ao primeiro horário com erro. Essa linha do tempo normalmente reduz o número de hipóteses e evita mudanças desnecessárias.

O que não fazer quando o cron para

• não executar o cron repetidamente como root;
• não apagar a tabela cron_schedule sem diagnóstico e backup;
• não abrir permissões de todos os arquivos para testar;
• não reiniciar banco, Redis ou servidor web sem evidência;
• não reindexar toda a loja se apenas um job apresenta erro;
• não levar uma correção sem validação diretamente para produção.

Conclusão

Quando o cron do Magento 2 não roda, a correção começa pela identificação da camada que falhou. Crontab ausente, usuário incorreto, PHP divergente, permissões, falta de espaço, jobs travados e serviços indisponíveis podem produzir sintomas semelhantes.

Se a loja acumula tarefas pendentes ou a falha afeta pedidos, estoque e integrações, preserve os logs e evite várias alterações simultâneas. A equipe do SuporteMagento.com.br pode ajudar a analisar o ambiente e planejar uma correção com menor impacto para a operação.

Perguntas frequentes sobre cron no Magento 2

Como verificar se o cron do Magento está instalado?

Execute crontab -l com o usuário responsável pelos arquivos da loja. Confirme se as entradas apontam para o caminho e o PHP corretos. Em ambientes gerenciados ou contêineres, o agendamento pode estar configurado em outra camada.

É seguro executar bin/magento cron:run manualmente?

Sim, como procedimento de diagnóstico, desde que seja usado o proprietário adequado do projeto e sejam considerados os recursos consumidos pelas tarefas. Evite executar como root ou repetir o comando continuamente em produção.

O que significa status missed na cron_schedule?

Significa que a janela programada para o job passou sem que ele fosse executado. Isso pode ocorrer por cron interrompido, sobrecarga, tarefa anterior muito demorada ou configuração inadequada do agendamento.

Posso apagar a tabela cron_schedule para corrigir o cron?

Não como primeira medida. A tabela contém informações úteis para o diagnóstico, e sua limpeza não resolve a causa da falha. Qualquer manutenção deve considerar backup, volume de dados e configuração de limpeza do próprio Magento.