The storefront reads an index, not the admin
When a Magento administrator saves a price, a stock level or a new product, the change goes to the database tables the admin uses. The storefront does not read those tables directly. It reads index tables that Magento builds from them, and the indexers are what keep the two in step. If the indexer has not run, the admin shows the new price and the product page still shows the old one, and both are doing what they were designed to do.
Adobe's documentation names two modes. Update on Save refreshes an index when a change is made in the admin. Update by Schedule refreshes it on the schedule set by the cron job. The price of schedule mode is a dependency: a recurring job must keep running.
- Update on Save: changes apply when saved.
- Update by Schedule: a background job applies them.
- Customer grid supported only Update on Save before 2.4.8; from 2.4.8 it supports both.
What schedule mode needs in place
In schedule mode, Magento adds database triggers that record each change into a change-log table, and the cron job later reads that log and updates the index. The reindex command is a one-time run, so it can fix the symptom once but cannot keep the storefront current; Adobe says a cron job is needed for that. If the job does not run, edits queue up unseen. If it runs and fails, the change-log tables grow. Adobe's knowledge-base article ties exactly this pattern to the job named indexer_update_all_views repeatedly failing to finish, and to triggers that are missing. That article is written for Adobe Commerce 2.2.x and 2.3.x, so check how it carries to your version.
- Cron not running: no recent runs of the indexing job.
- Cron failing: runs recorded with a status other than success or pending.
- Triggers missing: edits add no rows to the change-log table.
- Indexer suspended: automatic cron updates are paused until it is released.
Read-only checks a host can run first
Nothing here changes data. Ask your host or developer to run these on a staging copy and send the redacted output.
- The indexer status command: which indexers exist, their mode and whether any is invalid or suspended, with any backlog count.
- The indexer info command: the full list of indexers.
- A query on the scheduled jobs table for the indexing job and a status that is not success or pending.
- Whether any scheduled job ran in the last hour.
- Magento or Adobe Commerce version, since behaviour differs between 2.4 releases.
What fixes it, and the order to do it in
Fixes follow the cause. If the job is not running, restore the cron configuration. If it keeps failing, find why it fails and let it complete, then the change-log backlog clears. If triggers are missing, Adobe says to switch the indexer to realtime and back to schedule so they are recreated, and to put the site in maintenance mode and disable cron jobs first to avoid database locks. Setting an indexer to valid without checking that the data is indexed can leave stale data in place and degrade performance.
A full reindex of a large catalogue can take a long time, so plan it for a quiet period.
- Back up the database first, and avoid peak traffic.
- Run commands as the file system owner.
- Never mark an indexer valid just to clear a warning.
What does not fit
This guide covers staleness caused by indexers and cron. It does not cover a cache or content delivery layer serving old pages, search service faults, extensions that write data incorrectly, or data that is wrong in the admin itself. If a manual reindex makes no difference, look elsewhere. Performance tuning and upgrades are separate work.
How the paid fix is accepted
The fixed job for this problem is accepted on a staging copy. Every indexer is in the agreed mode and none is invalid or suspended, the scheduled job that applies index changes shows recent successful runs with none stuck pending, a test product price edit appears on its storefront page within the agreed time, and a test stock change appears in a category listing. Your host applies the change on live, in a maintenance window; we do not touch the live database.
Sources and limits
- Adobe Commerce documentation: Manage the indexers Checked 2026-10-11.
- Update on Save refreshes the index when a change is made in the Admin, while Update by Schedule refreshes it on the schedule set by the cron job.
- Database triggers are added in schedule mode and removed in realtime mode, and if they go missing, switching to realtime and back recreates them.
- The indexer reindex command runs once, so a cron job is required to keep indexers current in schedule mode.
- Invalid flags data as out of date so the next cron run reindexes it unless it is suspended, and suspended pauses automatic cron updates.
- Before switching modes, put the site in maintenance mode and disable cron jobs to avoid database locks.
- Before 2.4.8 the customer grid indexer supported only Update on Save; from 2.4.8 it supports both modes.
- Setting an indexer to valid when unindexed data has built up can degrade performance.
- Adobe Commerce knowledge base: Changes in the database are not reflected on the storefront Checked 2026-10-11.
- The article applies to Adobe Commerce 2.2.x and 2.3.x and ties stale storefront data to indexers configured to update by schedule.
- Causes named are oversized change-log tables, which grow when the indexer_update_all_views cron job repeatedly fails to finish, and missing MySQL triggers.
- Failed runs can be found by querying the cron schedule table for that job code with a status other than success or pending.
- The article asks for a backup first and avoiding heavy traffic.