Magento 2 cron not running?
Find the broken step before you restart.

The short answer

When Magento 2 cron appears to stop, first identify whether the scheduler failed to launch Magento, Magento stopped creating the expected schedule, or a particular task stopped completing. Reinstalling cron cannot repair every failure in that chain.

Start with the affected outcome: delayed asynchronous order emails, stale scheduled indexes, an integration backlog or a missed custom export. Record the job code, expected frequency and first known failure. If you need the wider operational picture, use our Magento 2 health-check guide.

Layer 1 / Launch

1. Verify what actually launches Magento

whoami
pwd
command -v php
php -v
php --ini
php bin/magento --version
crontab -l

On a conventional host, compare the cron entry with your active release directory and intended PHP binary. A correct entry under another user does not prove this deployment is covered. A command copied before a release switch may still point at old code.

Inspect the operating-system scheduler using your hosting tools. On Ubuntu/Debian with systemd and sufficient access, these are useful observations:

systemctl is-active cron
journalctl -u cron --since "30 minutes ago" --no-pager

The process-filter example later uses rg (ripgrep); use your host’s process viewer if it is unavailable. Other distributions may use crond; containers and managed hosts may use another launcher entirely. A service being active only proves the service is up. Look for attempts to execute this application’s command, then correlate those attempts with Magento evidence.

Expected: the intended scheduler repeatedly invokes the correct release, owner and PHP binary. If not: investigate a missing entry, stopped service, changed release path or incompatible CLI PHP configuration. Do not change permissions recursively to make the symptom disappear.

Layer 2 / Schedule

2. Inspect a bounded window of recent jobs

Use a time window appropriate to the task. One hour is useful for frequently scheduled work, but insufficient for a daily or weekly job. Check clock alignment before comparing application, database and host timestamps. These SQL windows assume a UTC database session; have your database operator confirm it before interpreting timestamp comparisons.

date -u
# In your database client, run the SQL below.

SELECT UTC_TIMESTAMP() AS observed_utc,
       @@session.time_zone AS session_time_zone;

SELECT schedule_id, job_code, status,
       created_at, scheduled_at, executed_at, finished_at
FROM cron_schedule
WHERE scheduled_at >= UTC_TIMESTAMP() - INTERVAL 1 HOUR
ORDER BY scheduled_at DESC, schedule_id DESC
LIMIT 100;

Then filter for the exact job you are investigating. The code below is an example for scheduled index updates; custom integrations have their own job codes.

SELECT schedule_id, job_code, status,
       scheduled_at, executed_at, finished_at
FROM cron_schedule
WHERE job_code = 'indexer_update_all_views'
  AND scheduled_at >= UTC_TIMESTAMP() - INTERVAL 1 HOUR
ORDER BY scheduled_at DESC, schedule_id DESC
LIMIT 30;

Take a second snapshot after the relevant scheduling interval. Compare the same rows as well as new rows. A list of old successes can coexist with a current outage. Missing history can reflect cleanup, a wrong database, an incorrect job code or a task that is not due—not just a broken launcher.

Layer 3 / Execution

3. Interpret states in context

A growing count by itself is not enough. Ask which tasks are due, how old the oldest due task is, and whether the delay exceeds the normal workload for that store. Pending work scheduled for tomorrow is not today’s backlog.

For a custom job, confirm its expected frequency and group with the module maintainer. Check effective configuration rather than assuming the XML schedule is the only source.

4. Match job timestamps to errors

tail -n 100 var/log/cron.log
tail -n 100 var/log/exception.log
tail -n 100 var/log/support_report.log

Inspect the launcher’s redirected output too; it may be a different file, such as var/log/magento.cron.log. A PHP startup failure can happen before Magento writes its own log. Missing log files can reflect rotation or logging configuration.

Correlate one job code and one execution window. Common investigation paths include an unavailable remote API, failed database access, a missing class after a deployment, or resource exhaustion. Preserve a sanitized exception signature and timestamp before applying a fix.

If unrelated jobs continue to finish while one repeatedly errors, focus on that task first. Restarting the system scheduler may not change the task’s failing dependency.

5. Check cron groups and queue consumers separately

A launcher restricted to one group cannot establish that every group is covered. Review intended group coverage and custom module definitions. The scheduling interval and allowed start window also influence whether a delayed invocation can run due work. See Adobe’s cron-group configuration reference.

Queues introduce another boundary. The cron runner may start consumers, or the host may supervise them separately. Inspect only the relevant runner configuration locally; do not paste the complete environment configuration into a support ticket.

php bin/magento queue:consumers:list
# Linux process snapshot; inspect locally for sensitive arguments.
ps -eo pid,ppid,user,etime,args | rg "[b]in/magento (cron:run|queue:consumers:start)"

The consumer list shows registrations, not throughput. An absent process can be normal for a short-lived worker, and a present process may be idle. Confirm queue age, expected messages and completed work before launching extra consumers. Refer to Adobe’s queue process-management guidance.

Illustrative timeline

Worked example: new rows, no completed work

This is a simulated example, not a customer incident. Assume vendor_inventory_sync is a custom job expected every five minutes.

10:00  scheduled_at=10:00  status=pending  executed_at=NULL
10:06  same row           status=missed   executed_at=NULL
10:06  unrelated job      status=success finished_at=10:05

What this supports: the target did not begin within its allowed window. Another job finishing makes a total application-wide stop less likely.

What it does not establish: the cause. Investigate the target’s group, effective schedule and start window, earlier long work, and launcher coverage. Do not invent a module exception when execution never started.

After correcting the confirmed cause, the evidence you want is a newly due row with a sensible execution/finish time, followed by a successful downstream inventory update. Keep watching automatic cycles after the manual test.

Prove automatic recovery

A manual success is a useful test, but it does not establish the launcher will run unattended. Record recovery evidence that someone else can review:

1. The application owner, release and PHP binary used by the scheduler are confirmed.
2. New due work for the affected job is created and completed over several expected automatic cycles.
3. The oldest overdue work stops aging; errors and missed jobs do not continue accumulating unexpectedly.
4. The downstream result is correct: the catalog update is visible, the export arrives or a controlled email reaches its destination.
5. The alert recipient and next review are assigned.

For infrequent jobs, define an observation period that includes the next due execution. An email-sent flag does not prove inbox delivery; an indexer success does not prove cache freshness. Use the wider health-check handoff checklist to record related findings.

Prevent the next silent failure

Track the age of the last relevant successful execution, overdue work and recurring task errors against a documented expected frequency. Review these checks after release-path, PHP, scheduler and module changes.

Application monitoring also has a dependency: if its own cron stops, it may stop producing fresh results or alerts. Pair internal checks with an independent heartbeat or an external review of missing observations.

Buildmerce Health Guard includes cron status monitoring, with scheduled checks and alerts described for Pro. Confirm the current product coverage and configuration; do not assume that an internal monitor independently detects its own scheduler outage.

Common questions

Sources & revision notes

• Magento source: cron_schedule schema (development branch; compare your installed release)
• Adobe: configure and run cron jobs
• Adobe: custom cron job and group reference
• Adobe: Commerce Cloud crons property
• Adobe: manage message queues

October 27, 2026 · First edition. Documentation-reviewed commands, bounded SQL, local investigation selector and recovery criteria. Examples are illustrative; no customer logs are published.

Continue with the complete Magento 2 health check, browse all Magento guides or send a technical correction.