Cron do Magento 2: o que monitorar, como configurar, como evitar travar

Se você opera Magento 2 e ainda não passou pela frase "acho que o cron travou", ou ele está travado agora e você não sabe, ou opera uma loja muito pequena. Cron é a coluna vertebral do Magento 2: sem ele, indexers não atualizam, pedidos não trocam de status, e-mail de boas-vindas não sai, sitemap não regenera, integrações ficam paradas. Este guia é o conjunto de práticas que evita o ciclo de "loja parece bem, mas pedidos estão sumindo".

O que o cron do Magento 2 faz

Diferentemente de cron Unix tradicional, o Magento 2 tem seu próprio agendador baseado em banco. O cron Unix invoca php bin/magento cron:run a cada minuto, e o Magento internamente:

1. Lê a tabela cron_schedule (jobs agendados).
2. Identifica os que estão prontos para executar (status = 'pending').
3. Trava cada um (status = 'running'), executa, e marca como 'success' ou 'error'.
4. Limpa jobs antigos (em teoria, mais sobre isso adiante).

Há 3 grupos distintos:

Setup recomendado em produção

Em vez do clássico:

# CRONTAB ANTIGO — RUIM em produção
* * * * * cd /var/www/magento && php bin/magento cron:run

Use processos separados:

# CRONTAB MODERNO — 1 entrada por grupo, com lock
* * * * * /usr/bin/flock -n /tmp/m2-cron-default.lock /var/www/magento/bin/magento cron:run --group=default
* * * * * /usr/bin/flock -n /tmp/m2-cron-index.lock /var/www/magento/bin/magento cron:run --group=index

Para os consumers, use supervisor ou systemd — não cron:

# /etc/supervisor/conf.d/magento-consumers.conf
[program:magento-consumer-async-operations]
command=php /var/www/magento/bin/magento queue:consumers:start async.operations.all --max-messages=1000
autostart=true
autorestart=true
user=magento
numprocs=1
stdout_logfile=/var/log/magento/consumer-async-ops.log

Diagnóstico rápido: o cron está saudável?

Check 1 — Algum job está rodando há mais de 30 min?

SELECT job_code, status, scheduled_at, executed_at,
       TIMESTAMPDIFF(MINUTE, executed_at, NOW()) AS minutes_running
  FROM cron_schedule
 WHERE status = 'running'
   AND executed_at IS NOT NULL
 ORDER BY executed_at ASC;

Se aparecer job rodando há > 30 min, está travado. Mate o processo (ps aux | grep cron:run, depois kill) e force o status para'error' manualmente — caso contrário o Magento espera ele "terminar" indefinidamente.

Check 2 — Backlog de jobs "missed"

SELECT job_code, COUNT(*) AS missed
  FROM cron_schedule
 WHERE status = 'missed'
   AND scheduled_at > NOW() - INTERVAL 7 DAY
 GROUP BY job_code
 ORDER BY missed DESC;

"missed" significa que o job foi agendado mas não executou na janela permitida — o cron estava ocupado ou parado. Mais que ~50 por dia em qualquer job é sinal vermelho.

Check 3 — Tabela cron_schedule não está inflando?

SELECT COUNT(*) FROM cron_schedule;
-- > 200.000 = purge agressivo está falhando

Purge da tabela cron_schedule

Em teoria, Magento purga jobs antigos automaticamente. Em prática, em loja com muitos jobs e custom modules, esse purge frequentemente nunca acontece — e a tabela cresce até travar o cron.

Configuração em Stores → Configuration → Advanced → System → Cron:

• History Cleanup Every: 60 min (ok)
• Success History Lifetime: 1440 min (1 dia) — pode reduzir para 360 min em loja grande
• Failure History Lifetime: 10080 min (7 dias) — útil para debug

Se mesmo assim a tabela inflar, force purge manual:

DELETE FROM cron_schedule
 WHERE created_at < NOW() - INTERVAL 7 DAY
   AND status IN ('success', 'error', 'missed');

-- Em loja grande, faça em lotes para não lockar:
DELETE FROM cron_schedule
 WHERE created_at < NOW() - INTERVAL 7 DAY
   AND status IN ('success', 'error', 'missed')
 LIMIT 50000;

A parte de queue consumers que cobre 80% dos "pedidos sumindo"

Em Magento 2 moderno (2.4+), boa parte do que parece "cron travado" é na verdade consumer travado. Os consumers processam:

• async.operations.all — operações bulk (import/export, mass actions)
• product_action_attribute.update — update em massa de atributo
• inventory.indexer.source.item — sincronização de MSI
• sales.rule.update.coupon.usage — uso de cupom

Veja a fila atual:

SELECT topic_name, COUNT(*) AS pendentes
  FROM queue_message qm
  JOIN queue_message_status qms ON qm.id = qms.message_id
 WHERE qms.status = 4  -- NEW (não processado)
 GROUP BY topic_name
HAVING pendentes > 50
 ORDER BY pendentes DESC;

Mais de 50 mensagens "NEW" em um tópico, e crescendo nos últimos 15 minutos, é consumer travado. Veja o detalhe completo em pedidos travados no Magento 2.

Monitoramento contínuo do cron

O monitoramento mínimo do cron tem 4 sinais — qualquer um disparando é alerta:

1. Job rodando há > 30 min em status running.
2. Job sem nenhuma execução nos últimos 30 min quando deveria rodar a cada 15 (e.g. indexer_update_all_views).
3. Tópico de queue com > 50 NEW e crescendo há 15 min.
4. cron_schedule com > 200k linhas — purge não está rodando.

Datadog, New Relic ou um cronjob próprio que rode esses checks e dispare webhook para Discord/Slack atende perfeitamente. A Especialista Loja Virtual tem isso como teste pré-configurado para Magento — basta apontar a credencial.

Erros comuns que matam o cron

Checklist final

1. Crontab separado por --group com flock ativo.
2. Consumers via supervisor com --max-messages e autorestart=true.
3. Purge de cron_schedule funcionando (tabela < 200k linhas).
4. Monitoramento dos 4 sinais ativo, com alerta em Slack/Discord.
5. Logs de consumer indo para /var/log/magento/, com rotação.
6. Indexers em "Update by Schedule", não "Update on Save" (este último derruba performance).
7. Custom cron.xml revisado — todo job com try/catch e logging.