If your Magento store feels slow or shows stale prices and stock, the cause is often cron and the indexers, not the storefront. Cron runs the background machinery: it processes the indexer queue, flushes cache, sends emails, and cleans up. When cron stops or an indexer gets stuck, indexes go invalid, admin saves slow down, and shoppers see outdated data. The fixes are usually straightforward: confirm cron is running, switch indexers to Update on Schedule, and clear any stuck reindex with a reset.
Indexers and cron are the parts of Magento that no shopper sees but every shopper feels. A healthy queue keeps category pages fast and data fresh; a broken one produces the mysterious slowness and stale-data complaints that send teams hunting in the wrong place. This guide explains how the machinery works, why it breaks, and how to keep it healthy.
What indexers do, and why they matter
Magento stores product data in a normalized structure that is flexible to edit but slow to query directly. Indexers transform that data into flat, fast-to-read index tables that the storefront queries instead. Price, catalog search, category product lists, and stock all rely on indexes. When an index is current, those pages are fast; when it is invalid, the store either serves stale data or falls back to slow, un-indexed queries.
There are several indexers, and each covers a specific concern: product price, catalog search, category products, stock, and more. The key status to watch is whether each is valid or invalid. An invalid indexer means the underlying data changed but the index has not caught up, so what shoppers see may be wrong until it does.
Update on Save versus Update on Schedule
Indexers run in one of two modes, and choosing correctly is the single most important indexer decision.
| Mode | How it works | Best for |
|---|---|---|
| Update on Save | Rebuilds the index immediately when you change data in admin | Development, very small catalogs |
| Update on Schedule | Batches changes and processes them through cron at intervals | Production stores, larger catalogs |
Update on Save rebuilds the index the moment you save a product, which makes every admin save slow and can lock up the admin during bulk edits. Update on Schedule instead records changes and lets cron process them in batches, which reduces server load and keeps the admin responsive. Update on Schedule is the default in Magento 2.4.8 and the correct choice for essentially every production store. If your admin crawls when editing products, switching to Update on Schedule is often the fix, and it is a standard part of Magento development hygiene.
Why cron is the heart of it all
Update on Schedule only works if cron runs. Cron is the scheduler that executes Magento’s background jobs, and processing the indexer changelog is one of them. When you edit a product in Schedule mode, Magento writes the change to a changelog table; cron later reads that changelog and updates the index. No cron, no index update.
This is why the error “one or more indexers are invalid, make sure your Magento cron job is running” is so common. It is Magento telling you the changelog is piling up because nothing is processing it. Cron also handles cache flushing, email sending, and cleanup, so a store with broken cron has problems well beyond indexing. Confirming cron is running and running often enough is the first thing to check when data goes stale.
Fixing a stuck indexer
Sometimes an indexer gets stuck in a working or locked state and refuses to run. This happens when a previous reindex grabbed a lock and then died before releasing it, killed by a timeout, an out-of-memory error, or a deploy mid-reindex. The lock and the working status never cleared, so every new reindex refuses to start, and the index stays stale.
The reliable fix is a short sequence:
- Reset the stuck indexer state with
bin/magento indexer:reset, which clears the working status. - Clear stale lock files with
rm -rf var/locks/*to remove the orphaned lock. - Reindex with extra memory using
php -d memory_limit=4G bin/magento indexer:reindex, so the reindex does not die again from an out-of-memory error.
That memory bump matters. Many stuck-indexer loops are really out-of-memory loops: the reindex dies from insufficient memory, leaves a lock, and the next attempt fails on the lock. Giving the reindex enough memory breaks the cycle.
Changelog bloat and the slow-reindex trap
There is a subtler failure than a stuck indexer: a changelog table that has grown huge. In Update on Schedule mode, every change writes to a changelog, and cron consumes it. If cron falls behind, is misconfigured, or was down for a while, the changelog grows, and a bloated changelog makes each reindex slower, which makes cron fall further behind. It is a spiral.
The signs are reindexing that takes longer over time and cron jobs that never seem to catch up. The fix is to get cron healthy and running frequently enough, then, if the changelog is severely bloated, reset the affected indexer so it rebuilds cleanly rather than grinding through an enormous backlog. Preventing it is better: monitor cron so it never falls far behind in the first place.
Keeping cron and indexers healthy
A maintenance routine that prevents most indexer problems:
- Run Update on Schedule on all indexers in production.
- Verify cron runs on a proper schedule, typically every minute, and that it completes without errors.
- Monitor indexer status so an invalid index is caught quickly, not discovered through a shopper complaint.
- Watch changelog table sizes as an early warning that cron is falling behind.
- Give reindexing enough memory so scheduled reindexes do not die and leave locks.
- Reindex after major data imports so a large catalog update does not leave indexes stale for long.
None of this is glamorous, but it is the difference between a store that stays fast and fresh and one that mysteriously slows and serves stale data.
Setting up cron correctly
Most cron problems are setup problems. Magento cron should run through the operating system’s scheduler, calling Magento’s cron command on a regular interval, typically every minute. A single crontab entry that runs the Magento cron is enough for many stores, but a few details separate a healthy setup from a fragile one.
Run cron as the correct user, the same user that owns the Magento files, so it does not create files the web server cannot read or write. Log cron output so you can see failures instead of guessing. And make sure only one cron scheduler is configured, because duplicate cron setups, a crontab entry plus a control-panel scheduler, for example, cause jobs to run twice and can corrupt the schedule. On larger stores, running separate cron groups for indexing and for other jobs prevents a slow reindex from blocking time-sensitive tasks like order emails.
After any deploy or server migration, re-verify cron. It is one of the most common things to be silently lost in a migration, and the store keeps working for a while, until the changelog backs up and indexes go stale. A quick check that cron is running and the schedule table is being processed belongs on every post-deploy checklist.
Message queue consumers: the other background workers
Indexing is not the only background work Magento does. Adobe Commerce and modern Magento use message queues for asynchronous tasks, bulk operations, inventory updates, integration syncs, and more. Those queues are processed by consumers, which are long-running processes that need to be kept alive, usually by a process manager or by cron starting them.
The failure mode mirrors the indexer one: if consumers are not running, messages pile up in the queue and the work they represent never completes. Bulk actions appear to hang, integrations fall out of sync, and no obvious error appears on the storefront. When diagnosing a store where background work is not happening, check both cron and the message queue consumers, because either can be the silent culprit. A complete health check covers the whole background-processing picture, not just the indexers, so nothing important is quietly stuck.
Frequently asked questions
Why does my Magento store show stale prices or stock?
Usually an invalid indexer or a cron that is not running. In Update on Schedule mode, price and stock changes are written to a changelog that cron processes into the index. If cron is down or an indexer is stuck, the index never updates and shoppers see outdated data until it is fixed.
Should I use Update on Save or Update on Schedule?
Update on Schedule for any production store. Update on Save rebuilds indexes immediately and slows every admin save, which is fine only for development or tiny catalogs. Update on Schedule batches changes through cron, keeps the admin responsive, and is the default in Magento 2.4.8.
How do I fix a stuck Magento reindex?
Reset the indexer state with bin/magento indexer:reset, clear stale locks with rm -rf var/locks/*, then reindex with extra memory using php -d memory_limit=4G bin/magento indexer:reindex. The memory increase prevents the reindex from dying again and leaving a new lock.
What does “make sure your Magento cron job is running” mean?
It means the indexer changelog is piling up because cron is not processing it. Magento relies on cron to update indexes in Schedule mode, flush cache, and send emails. Confirm cron is configured, running every minute, and completing without errors.
Why is my reindex getting slower over time?
Often a bloated changelog table. If cron falls behind, changes accumulate in the changelog, and each reindex has more to process, which makes cron fall further behind. Get cron healthy and running frequently, and reset severely bloated indexers so they rebuild cleanly.
Where this fits
Cron and indexers are the invisible machinery that keeps a Magento store fast and its data fresh. Run indexers on Update on Schedule, keep cron healthy and frequent, fix stuck reindexes with a reset and enough memory, and watch for changelog bloat. Do that, and the mysterious slowness and stale-data complaints that plague neglected stores simply do not happen.
Bemeir is the first US-based Hyva partner and a full Adobe Commerce agency, with a deep technology partner ecosystem across hosting, monitoring, and infrastructure. We keep cron, indexers, and the queue healthy on Hyva and Magento builds, and we also work across Shopify, Shopware, and BigCommerce. Read more about Bemeir and how we keep Magento stores healthy.
External references: a guide to Magento index management and update modes, Adobe’s Magento Indexer module reference, and a walkthrough for fixing invalid indexers and cron.
