Magento Index Management: On Save vs On Schedule

Indexing decides whether the storefront tells the truth

Magento's indexers turn raw catalog and price data into the fast, denormalized tables the storefront reads. When they fall behind, customers see stale prices, wrong stock, and missing search results.

The choice between updating indexes on save and updating them on a schedule shapes how the store behaves under change and under load. Getting it wrong causes either admin slowness or stale storefront data.

This article covers how the indexers work, the two update modes and when each fits, the changelog mechanism behind scheduled indexing, and how to keep indexing healthy.

What the indexers actually do

Magento maintains a set of indexers, each responsible for one kind of derived data. Price, stock, catalog category relationships, catalog rules, and full-text search each have their own indexer.

You can list them with bin/magento indexer:info, which shows every indexer the store runs. Each one reads source data and writes the flat index tables the storefront queries, so the storefront never has to compute that data live.

This is why indexing matters so much for performance. The index tables exist precisely so category pages, search, and pricing can be fast, and they are only useful when they are current.

The two update modes

Each indexer runs in one of two modes. Update on save reindexes immediately whenever the relevant data changes, and update on schedule defers the work to cron.

On save, editing a product triggers an immediate reindex of the affected data, which keeps the storefront current but makes saves slower. On schedule, the change is recorded and processed later by cron, which keeps saves fast but introduces a delay before the storefront reflects it.

Why busy stores use schedule

On a store with frequent catalog changes, update on save becomes a problem. Every product save triggers reindexing, and a bulk update or import can trigger an enormous amount of immediate index work.

That work happens synchronously, so imports crawl and admin saves lag. On save also does not batch, so a hundred product changes are a hundred separate reindex operations rather than one.

Update on schedule solves this by batching. Changes accumulate, and cron processes them together, which is far more efficient for a store that changes its catalog regularly.

The changelog behind scheduled indexing

Scheduled indexing works through the materialized view mechanism. When an indexer is on schedule, Magento records what changed in a changelog table, one per indexer, with a _cl suffix.

Cron then reads those changelog tables and reindexes only the changed entities, rather than rebuilding everything. This partial approach is what makes scheduled indexing efficient, since it processes deltas instead of the whole catalog.

The changelog tables are worth knowing about because they can grow. A changelog that is not being consumed, because cron is unhealthy, is both a sign of a problem and a table that keeps growing.

Setting the mode

The indexer mode is set from the command line. bin/magento indexer:set-mode schedule switches indexers to scheduled, and the realtime option switches them back to update on save.

You can set the mode per indexer or across all of them. Most stores of size run all indexers on schedule, with cron handling the reindex work in the background.

Confirm the current mode with bin/magento indexer:status, which shows each indexer's mode and whether it is valid or invalid. That status is the first thing to read when storefront data looks stale.

When the schedule falls behind

Scheduled indexing depends entirely on cron. When cron is unhealthy or overwhelmed, the changelog accumulates faster than it is processed, and the index falls behind.

The symptom is stale storefront data: new products not appearing, price changes not reflecting, stock not updating. The index is not broken; it is simply behind, because the cron that feeds it is not keeping up.

Dimension modes for the price index

The price index has an extra lever worth knowing. Its dimension mode controls how the index is partitioned, which affects both its size and how it reindexes.

Using bin/magento indexer:set-dimensions-mode, the price index can be split by website, by customer group, or both. On a store with many customer groups and websites, choosing the right dimension mode can significantly change reindex time and index size.

This is an advanced tuning option, not a default concern, but it matters on large multi-site or multi-group stores. The wrong dimension mode there can make the price index unnecessarily heavy.

Reindexing manually

Sometimes you need to reindex on demand, after a bulk change or to recover from a stale index. bin/magento indexer:reindex rebuilds the indexes, optionally targeting specific ones.

A full reindex is expensive on a large catalog and competes for resources, so it belongs in a maintenance window rather than at peak traffic. Targeting a single stale indexer is lighter than rebuilding everything.

Reindexing is also the recovery step when an indexer is stuck invalid. Once the underlying cause is fixed, a reindex brings the storefront data back in line with the source.

Indexing and imports together

Large imports and indexing interact in ways worth planning for. An import on a store with indexers on save triggers massive immediate reindexing, which is why imports on such stores are painfully slow.

With indexers on schedule, the import records its changes to the changelog and returns quickly, leaving cron to reindex the deltas afterward. This is far better for the import itself, though it means the storefront lags until cron catches up.

For very large imports, some teams disable indexing during the import and reindex once at the end. That turns thousands of incremental reindexes into a single batch, which is the most efficient path for a big load.

What changed in recent versions

Indexing has been refined across the 2.4.x line, with improvements to how scheduled indexing batches and processes changes. The general direction has been toward making scheduled indexing the reliable default for stores of size.

The specifics vary by exact version, so confirm the behavior for the release you run. The principles hold across versions even as the internals improve: schedule for busy stores, keep cron healthy, and watch for the index falling behind.

The takeaway is that scheduled indexing is not a workaround, it is the intended mode for a real store. On save exists for development and small catalogs, not for a busy production store.

Which indexers matter most

Not every indexer carries the same weight. A few are central to the storefront experience and deserve the most attention:

• The price index, which is often the heaviest and most affected by customer groups and websites.
• The catalog category and product relationship indexes, which drive what appears on category pages.
• The stock index, which keeps salable quantity current.
• The full-text search index, which feeds catalog search.

When storefront data looks wrong, the symptom points at which indexer to check. Wrong prices point at the price index, missing search results at the search index, and wrong stock at the inventory index.

Reading the indexer status

The bin/magento indexer:status output is the first read for any indexing concern. It lists each indexer with its mode and its state, either valid or invalid.

Valid means the index reflects the current source data. Invalid means the index is behind and a reindex is pending, which on a scheduled store should be temporary as cron catches up.

An indexer stuck invalid, that never returns to valid, is the real problem. It means either cron is not processing the changelog or a reindex is failing, and the storefront data will stay stale until it is resolved.

The invalid state that never clears

A persistently invalid indexer is a specific, findable failure. The two usual causes are cron not running the index group, or a reindex erroring partway.

Check cron health first, since scheduled indexing depends on it, then attempt a manual reindex of the stuck indexer to surface any error. The error, or the return to valid, tells you which cause you were dealing with.

Suspending indexers for bulk work

For very large catalog operations, the most efficient approach is to stop reindexing during the work and reindex once at the end. This turns thousands of incremental reindexes into a single batch.

The pattern is to run the bulk import or update, then trigger a full reindex of the affected indexers afterward. On a large import, this is dramatically faster than letting each change reindex as it lands.

The tradeoff is that the storefront data is stale during the import and the final reindex. That is acceptable for a planned bulk operation in a maintenance window, which is exactly when large imports should run.

Multi-website and multi-store stores

Stores with multiple websites, store views, and customer groups multiply the indexing work. The price index in particular expands with each combination it must compute.

This is where the price index dimension mode matters most, since it controls how that combinatorial work is partitioned. A large multi-site store with the wrong dimension mode can have a price index far heavier than it needs to be.

The reindex time on these stores is worth measuring specifically. What is fast on a single-site store can become a long operation across many sites and groups, which affects how current the data stays.

Monitoring the changelog

The changelog tables are an early-warning signal for scheduled indexing. When cron is keeping up, they stay small, because entries are processed shortly after they are written.

A changelog table that is growing is cron falling behind before the storefront visibly lags. Watching the size of the _cl tables gives you a lead indicator, catching an indexing backlog while it is still small.

Common indexing mistakes

A few mistakes recur across stores. Each turns indexing from a background process into a visible problem:

• Running indexers on save on a busy store, so imports and saves are painfully slow.
• Running on schedule but with unhealthy cron, so the index silently falls behind.
• Full reindexing at peak traffic instead of in a maintenance window.
• Ignoring a persistently invalid indexer until customers report stale data.

All four are avoidable with the habits above. The pattern is that indexing problems are usually cron or scheduling problems wearing an indexing costume.

Indexing and cache invalidation together

Indexing and cache invalidation are linked, because reindexing changes data that cached pages depend on. When an indexer processes a batch of changes, the cache for the affected content is invalidated too.

This means a large reindex can also trigger broad cache invalidation, and the two effects compound. A big catalog update that reindexes heavily can also clear a large part of the cache, producing a slowdown from both directions at once.

Planning heavy indexing for off-peak windows handles both. The same maintenance window that keeps reindexing off peak traffic also keeps the cache invalidation it triggers from landing on customers.

Resetting and forcing a rebuild

Sometimes you need to force every indexer to rebuild, after a major data change or to recover from a bad state. bin/magento indexer:reset marks the indexers invalid, so the next scheduled or manual run rebuilds them.

This is a heavier action than a targeted reindex, since it invalidates everything. It belongs in a maintenance window, because the rebuild that follows competes for resources and leaves data momentarily stale.

Reset is a recovery tool, not a routine one. When indexes are in a confused state and you want a clean rebuild, it is the way to force one, but a targeted reindex is the everyday option.

Testing index changes on staging

Changing indexer modes or dimension settings affects behavior and performance, so it belongs on staging first. A mode change that helps one store can slow another, depending on catalog size and change frequency.

Test the change on a staging environment that matches production in data volume, and measure the reindex time and storefront freshness before and after. A dimension mode change on the price index, in particular, has effects that only show at production scale.

This is the same measure-before-and-after discipline that applies to database and cache tuning. Indexing configuration is a performance lever, and levers should be tested, not flipped on production and hoped for.

The performance payoff of a current index

The reason all of this matters is the storefront. The index tables exist so category pages, search, and pricing are fast, and they only deliver that speed when they are current and healthy.

A store with healthy, current indexes serves accurate data quickly. A store with a lagging or broken index serves stale data, or falls back to slower paths, which shows up as both wrong information and slower pages.

Indexing is easy to treat as invisible plumbing until it fails. Kept healthy, it is one of the quiet foundations of a fast, accurate storefront.

Keeping indexing healthy

Healthy indexing comes down to a few habits. Run the indexers on schedule, keep cron healthy so the changelog is consumed, and watch the indexer status for anything stuck invalid.

Monitor the changelog tables for growth, since a growing changelog means cron is falling behind before customers notice. Plan large imports and full reindexes for off-peak windows so they do not compete with traffic.

The mode choice is the foundation. Update on schedule for any store with regular catalog change, healthy cron to feed it, and a watch on the changelog so you catch a backlog before customers do. Update on save only for development or the smallest, rarely-changing catalogs.

Knowing which mode your indexers run in, whether cron is keeping the index current, and how your imports interact with indexing is what keeps the storefront telling customers the truth. That indexing health check is a core part of a performance and stability review.