Magento cron and indexers: how to set them up and fix common problems

Many Magento problems that look unrelated turn out to have the same cause. Order confirmation emails stop arriving. A price change does not appear on the storefront. Catalog price rules never start. Products added to a category are missing from search. Behind most of these is a cron job that is not running, or an indexer that has fallen behind.

Adobe's documentation is blunt about it: Magento depends on correct cron configuration for many important functions, including indexing, and without it "Commerce will not function as expected". Cron drives catalog price rules, newsletters, sitemaps, product alerts, currency rate updates and all Commerce emails, including order confirmations.

This guide explains how cron and indexers work together in Magento Open Source and Adobe Commerce 2.4, how to set them up correctly, and how to diagnose the most common failures. The commands come from Adobe's configuration guide as updated in 2026.

How cron and indexers fit together

Magento runs a single system cron entry every minute: bin/magento cron:run. That command reads the jobs defined by every module, writes upcoming runs into the cron_schedule database table, and executes jobs whose time has come. Adobe notes that cron effectively runs twice for any task: the first run discovers what to schedule, and a later run, at or after the scheduled_at time, executes it.

Indexers turn the normalised catalog data into flat, fast tables that the storefront reads. Each indexer runs in one of two modes:

In schedule mode, which is the usual choice for production, indexing depends entirely on cron. If cron stops, the backlog grows and the storefront quietly drifts away from what the Admin shows.

Set up the Magento crontab correctly

Since version 2.2, Magento can write its crontab for you. Switch to the file system owner (all bin/magento commands must run as that user), go to the installation directory and install it:

sudo -u <file-system-owner> -s
cd /var/www/html/magento2
bin/magento cron:install
crontab -l

The result sits between marker comments. A typical entry looks like this:

#~ MAGENTO START c5f9e5ed71cceaabc4d4fd9b3e827a2b
* * * * * /usr/bin/php /var/www/html/magento2/bin/magento cron:run 2>&1 | grep -v "Ran jobs by schedule" >> /var/www/html/magento2/var/log/magento.cron.log
#~ MAGENTO END c5f9e5ed71cceaabc4d4fd9b3e827a2b

Some rules from Adobe's guide that prevent most cron trouble:

• Run cron on one node only. In a multi-server setup, the crontab must run on a single node.
• Use the same PHP settings for the command line as for the web server, especially memory limits.
• Remove leftovers. update/cron.php and bin/magento setup:cron:run were removed in 2.4.0, and dev/tools/cron.sh no longer exists. Delete any crontab lines that still call them.
• Do not edit inside the markers. cron:install does not rewrite an existing Magento block; use cron:install --force to replace it. Lines outside the markers are never touched.

Diagnose cron problems

Start with the logs. Cron output goes to var/log/cron.log. Jobs with an ERROR or MISSED status are also written to var/log/support_report.log, errors are logged as CRITICAL in var/log/exception.log, and in developer mode missed jobs appear in var/log/debug.log.

Then look at the cron_schedule table, which records each job's code, status and created, scheduled, executed and finished times. A grouped query shows quickly whether jobs are running at all:

SELECT job_code, status, COUNT(*) AS jobs, MAX(executed_at) AS last_run
FROM cron_schedule
GROUP BY job_code, status
ORDER BY last_run DESC
LIMIT 50;

You can also run one group by hand to watch it work: bin/magento cron:run --group index for indexing or bin/magento cron:run --group default for everything else.

Check and configure the indexers

Two commands tell you the state of every indexer:

bin/magento indexer:status
bin/magento indexer:show-mode

indexer:status shows each indexer's status, its mode, and in schedule mode the backlog size ("idle (0 in backlog)" is what you want). A large or growing backlog means cron is not keeping up; a status of "Reindex required" means the indexer has been invalidated.

To switch all indexers to schedule mode, Adobe advises putting the site into maintenance mode and disabling cron first, to avoid database locks:

bin/magento maintenance:enable
bin/magento cron:remove
bin/magento indexer:set-mode schedule
bin/magento cron:install
bin/magento maintenance:disable

One change to remember: before 2.4.8 the Customer Grid indexer supported only Update on Save. From 2.4.8 it supports both modes and defaults to Update by Schedule.

Fix the most common indexer problems

Changes never reach the storefront

If indexers are in schedule mode but changes are not picked up, the database triggers may be missing, for example after a database restore. Adobe's fix is to switch the affected indexer to realtime, which removes the triggers, and back to schedule, which recreates them:

bin/magento indexer:set-mode realtime catalog_product_price
bin/magento indexer:set-mode schedule catalog_product_price

An indexer stays invalid

Run bin/magento indexer:reindex for the named indexer. This is a one-off rebuild; Adobe stresses that it does not replace cron. Reindexing everything can take a long time on large catalogs, so name the indexers you need.

Large imports slow everything down

Since 2.4.7 you can suspend indexers during heavy operations with indexer:set-status. A suspended indexer is skipped by cron, along with any indexers that share its index. Afterwards, mark it invalid so the next cron run rebuilds it:

bin/magento indexer:set-status suspended catalog_category_product catalog_product_category
# ... run the import ...
bin/magento indexer:set-status invalid catalog_category_product catalog_product_category
bin/magento cron:run --group index

Be careful with setting an indexer straight to valid: Adobe warns this can hide unindexed data and degrade performance.

Full reindexing takes too long

Some indexers can run in parallel. Catalog Search Fulltext and Category Product are parallelised by store view by default. The price indexer can be split by website, customer group or both, and the thread count comes from the MAGE_INDEXER_THREADS_COUNT variable. PHP's pcntl extension must be enabled.

bin/magento indexer:set-dimensions-mode catalog_product_price website
MAGE_INDEXER_THREADS_COUNT=3 php -f bin/magento indexer:reindex catalogsearch_fulltext

Message queue consumers and cron

Many asynchronous features, such as bulk actions and some imports, publish messages to a queue that consumer processes read. On standard installations, cron starts those consumers through the consumers cron group, so a broken crontab also means queued work piles up.

Consumers matter most during deployments. Adobe's upgrade guide warns that starting an upgrade while consumers are running can corrupt data. Its procedure is to remove the crontab, run bin/magento cron:run --group=consumers once by hand so remaining messages are processed, and wait until ps aux | grep 'bin/magento queue' shows no consumer processes before continuing. Reinstall the crontab when the deployment is finished.

Questions to ask your hosting provider

Managed hosting plans differ in how much control they give you over cron and PHP. Before you blame Magento for missing emails or stale indexes, confirm these points with your host:

• Does the platform allow a per-minute crontab, and under which user does it run?
• On a multi-server setup, which single node runs cron, and what happens if that node fails?
• Does the command-line PHP use the same version and memory limit as PHP-FPM?
• Is the pcntl extension available for parallel reindexing?
• Are var/log files rotated, and can you ship them to your monitoring tool?

A short operations checklist

• One Magento crontab, on one node, installed as the file system owner.
• All indexers in schedule mode in production, with a backlog close to zero.
• Alerts when cron_schedule has no recent successful runs or many error rows.
• Indexers suspended during large imports and invalidated afterwards.
• Cron removed and message-queue consumers drained before upgrades, then cron reinstalled.

Summary

When emails stop, prices lag or search results look stale, check cron first and indexers second. Install the crontab with cron:install, read cron.log and the cron_schedule table, keep indexers in schedule mode, and use the realtime-then-schedule switch to restore missing triggers. These habits fix most "random" Magento problems before customers notice them.