Cron Magento 2 parou? 9 testes para destravar e-mails, índices e filas

Cron Magento 2 parado pode atrasar indexadores, regras de preço, e-mails, integrações e outras rotinas que deveriam funcionar em segundo plano. O problema nem sempre está no agendador do servidor: PHP CLI incompatível, permissões, tarefas sobrepostas ou uma execução específica com erro também podem bloquear o fluxo.

Antes de limpar a tabela cron_schedule, reiniciar serviços ou recriar o agendamento, registre o horário do incidente e escolha uma rotina afetada. Os nove testes abaixo ajudam a localizar a interrupção sem apagar as pistas mais importantes.

Cron Magento 2 parou: quais sintomas devem ser verificados?

Comece separando uma falha geral de um problema restrito a determinado módulo ou grupo de tarefas. Observe se a loja apresenta um ou mais destes sintomas:

• e-mails transacionais atrasados ou não enviados;
• indexadores configurados por agendamento permanecem pendentes;
• regras de catálogo não entram ou não saem de vigor no horário esperado;
• feeds, ERP ou marketplaces deixam de sincronizar;
• filas acumulam mensagens sem processamento;
• tarefas aparecem repetidamente como missed ou error;
• arquivos de log deixam de receber registros das execuções.

Nem todo atraso confirma uma falha global do cron. Se apenas as mensagens da loja não chegam, por exemplo, siga também o diagnóstico para quando o checkout Magento 2 apresenta falhas, caso o problema comece antes da criação do pedido. Para divergências no catálogo, verifique se o sintoma está relacionado ao agendamento ou ao próprio processamento do índice.

1. Registre a extensão e o horário da falha

Anote quando o problema foi percebido, qual tarefa deveria ter sido executada e quando ela funcionou pela última vez. Compare pedidos, produtos, visões de loja e integrações diferentes. Uma falha iniciada depois de deploy, troca de servidor, alteração de PHP ou atualização de extensão oferece uma direção, mas precisa ser confirmada nos registros.

Verifique também o fuso horário do sistema operacional, do PHP e da configuração da loja. Diferenças de horário podem fazer uma tarefa parecer atrasada quando ela foi agendada ou registrada em outra referência temporal.

2. Confirme se existe um agendamento no usuário correto

No servidor, consulte o crontab do usuário responsável pela aplicação:

crontab -l

Se a infraestrutura executar o Magento com outro usuário, faça a consulta no contexto correspondente. Não conclua que o cron está ausente apenas porque a conta usada no acesso SSH não apresenta entradas.

Confira o caminho do PHP, o diretório da aplicação e o destino dos logs. Migrações e mudanças de release podem deixar o crontab apontando para uma pasta antiga. Em ambientes conteinerizados ou gerenciados, o disparo pode estar em um scheduler externo, portanto a ausência no crontab local não representa necessariamente uma falha.

3. Compare o PHP CLI com o PHP da aplicação

O cron é executado pelo PHP de linha de comando, que pode ser diferente daquele usado pelo servidor web. Verifique:

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

Compare versão, extensões carregadas, limites de memória e arquivo php.ini. Uma extensão disponível no PHP-FPM, mas ausente no CLI, pode interromper a rotina mesmo quando o storefront continua funcionando.

Execute os comandos com o mesmo usuário do cron. Rodar manualmente como root pode mascarar permissões incorretas e criar arquivos que o usuário normal da aplicação não conseguirá modificar depois.

4. Execute o cron manualmente sem ocultar a saída

Na raiz da instalação e com o usuário adequado, execute:

php bin/magento cron:run

Preserve toda a saída, inclusive avisos apresentados antes da mensagem final. Se houver grupos separados, uma verificação controlada pode ser feita com:

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

Não repita o comando continuamente. Algumas tarefas apenas são agendadas na primeira passagem e processadas em uma execução posterior. Repetições simultâneas também podem criar concorrência e dificultar o diagnóstico.

5. Cruze os logs da aplicação, do cron e do sistema

Verifique os arquivos em var/log, o destino definido no crontab, os logs do PHP e os registros do serviço responsável pelo agendamento. Procure pelo horário exato da falha e preserve o primeiro erro, não somente a última exceção.

Mensagens de falta de memória, arquivo inexistente, conexão recusada, permissão negada ou classe ausente apontam para causas diferentes. Se a execução termina com erro HTTP ou falha genérica da aplicação, o roteiro de diagnóstico do erro 500 no Magento 2 ajuda a correlacionar PHP, servidor web e logs do Magento.

6. Analise a tabela cron_schedule sem apagar registros

A tabela cron_schedule mostra tarefas pendentes, executadas, perdidas e encerradas com erro. Se a instalação usar prefixo de tabelas, ajuste o nome nas consultas. Comece por uma visão agrupada:

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

Depois, examine as tarefas problemáticas mais recentes:

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

Muitos registros missed podem indicar que o scheduler não foi acionado no intervalo esperado ou que execuções anteriores consumiram os recursos disponíveis. Uma única tarefa em error, por outro lado, pode apontar para um módulo específico. Não esvazie a tabela antes de registrar os códigos, horários e mensagens.

7. Procure processos presos e execuções sobrepostas

Consulte os processos ativos usando as ferramentas disponíveis no servidor:

ps aux | grep -E 'bin/magento|cron:run' | grep -v grep

Observe duração, usuário e quantidade de processos. Uma execução longa não deve ser encerrada automaticamente: importações, atualizações de regras ou tarefas de terceiros podem realmente exigir mais tempo. Primeiro identifique o job_code, consulte os logs e confirme se há progresso.

Também verifique limites de CPU, memória, disco, processos e conexões com banco de dados. Reiniciar o serviço sem descobrir a causa pode liberar temporariamente o cron, mas permite que o bloqueio retorne no próximo ciclo.

8. Teste os serviços usados pela tarefa com erro

O scheduler pode funcionar enquanto uma rotina falha ao acessar banco, mecanismo de busca, Redis, fila, SMTP, ERP ou API externa. Relacione o job_code encontrado ao módulo responsável e teste apenas as dependências necessárias para aquela execução.

Quando o impacto aparece no estoque, confirme se reservas, fontes e indexadores estão coerentes antes de atribuir tudo ao cron. O guia sobre estoque Magento 2 que não atualiza mostra como separar quantidade física, saldo vendável e integração.

Extensões personalizadas também merecem atenção. Uma exceção não tratada, consulta lenta ou chamada externa sem tempo limite pode ocupar o worker e atrasar tarefas posteriores.

9. Corrija a causa e valide um ciclo completo

A correção depende da evidência encontrada: ajustar caminho do PHP, restaurar o agendamento, corrigir propriedade de arquivos, tratar a exceção de um módulo ou recuperar uma dependência indisponível. Faça a mudança primeiro em homologação sempre que possível e mantenha uma forma clara de reversão.

Depois da correção, acompanhe pelo menos um ciclo completo. Confirme que novas linhas são criadas na cron_schedule, passam de pending para running e terminam como success. Valide ainda o efeito funcional: índice atualizado, e-mail processado, regra aplicada ou integração concluída.

Evite usar a limpeza de cache como comprovação. O cache pode alterar o que aparece no frontend, mas não demonstra que o scheduler voltou a executar as tarefas corretamente.

Como evitar que o cron pare silenciosamente?

• monitore a quantidade e a idade de tarefas pending, missed e error;
• gere alertas quando uma rotina crítica deixar de concluir no intervalo esperado;
• registre duração e consumo de tarefas personalizadas;
• homologue extensões que adicionem novos jobs;
• revise crontab, caminhos e PHP CLI após migrações ou deploys estruturais;
• mantenha logs com retenção suficiente para investigar incidentes.

Perguntas frequentes sobre cron Magento 2

Posso apagar a tabela cron_schedule para destravar o cron?

Não como primeira medida. A tabela contém horários, estados, códigos e mensagens úteis para o diagnóstico. Apagar registros pode remover evidências sem corrigir PHP, permissões, dependências ou tarefas defeituosas.

Executar bin/magento cron:run uma vez resolve?

Nem sempre. Uma execução manual ajuda a revelar erros, mas algumas tarefas são agendadas em uma passagem e processadas depois. Também é necessário confirmar que o scheduler automático continuará chamando o comando.

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

As causas comuns incluem usuário diferente, caminho incorreto do PHP, variáveis de ambiente, diretório antigo, permissões e configuração do agendador. Compare o contexto da execução manual com o contexto real do cron.

O cron parado pode afetar o checkout?

Pode afetar processos posteriores ou assíncronos, como e-mails, integrações, filas e atualizações de dados. Porém, um checkout travado também pode ter origem em JavaScript, sessão, frete ou pagamento e deve ser investigado separadamente.

Conclusão

Quando o cron Magento 2 para, o melhor caminho é preservar os registros, delimitar as tarefas afetadas e comparar agendamento, PHP CLI, processos, tabela cron_schedule e serviços dependentes. Isso evita correções genéricas que apenas escondem o problema.

Se sua operação continua acumulando tarefas ou o erro retorna depois do reinício, uma análise técnica do ambiente pode identificar a causa e validar a recuperação. A equipe do SuporteMagento.com.br pode apoiar o diagnóstico e a estabilização da loja.