The storefront shows an index, so it can disagree with the admin
Magento keeps what the admin edits separate from what shoppers see. Shoppers read index tables, and indexers rebuild them from the admin data. In Update by Schedule mode the rebuild is done by a recurring cron job. If that job does not run, or keeps failing, a price change saved in the admin does not appear on the product page, although the admin itself looks right. Adobe's documentation states that the one-time reindex command cannot keep indexers current and that a cron job is needed.
- Admin right and storefront stale is the classic sign.
- A manual reindex that helps only for a while points at the recurring job.
- Behaviour differs between 2.4 releases, so the version matters.
What fails quietly
Adobe's knowledge base article for Adobe Commerce 2.2.x and 2.3.x names two causes under schedule mode: change-log tables that grow too large because the indexing job repeatedly fails to finish, and database triggers that have gone missing. Indexers can also be flagged invalid, or suspended, which pauses automatic cron updates. None of these shows a message to a shopper or to an administrator saving a product.
- Look at indexer status, not just the admin.
- Look at the scheduled job history for failures.
- Do not mark an indexer valid just to clear a warning.
Care before changing modes on a live store
Switching an indexer's mode to recreate triggers is a documented fix, but Adobe says to put the site in maintenance mode and disable cron jobs first, to avoid database locks. A full reindex of a large catalogue can take a long time. For those reasons the work is done and timed on a staging copy first, and your host applies it on live in a maintenance window.
The catalogue export if you are leaving
Magento exports products as CSV from the admin's data transfer area, in the background, through a queue that needs cron to be running. A configurable product is one row plus a row for each of its simple products, linked through a column of SKU-and-attribute entries. A move to another platform starts by reshaping those rows, which the catalogue-move guide and the Shopify file job describe.
What a paid outcome covers here
The fixed job for a storefront that does not show changes works on a staging copy: it checks indexer status, the indexing job history and the triggers, corrects what is wrong, and proves a test product edit appears within an agreed time. Your host applies it on live. Cache or content delivery layers, extension bugs, performance tuning and upgrades are outside it.
Sources and limits
- Adobe Commerce documentation: Manage the indexers Checked 2026-10-11.
- Update by Schedule refreshes the index on the cron schedule, and the reindex command runs once, so a recurring cron job is needed in schedule mode.
- Indexers can be invalid or suspended, and missing database triggers are recreated by switching the mode to realtime and back.
- Before switching modes the site should be in maintenance mode with cron jobs disabled to avoid database locks.
- Adobe Commerce knowledge base: Changes in the database are not reflected on the storefront Checked 2026-10-11.
- For Adobe Commerce 2.2.x and 2.3.x, stale storefront data under schedule mode is tied to oversized change-log tables, which grow when the indexer_update_all_views job repeatedly fails to finish, or to missing triggers.
- Adobe Commerce documentation: Export data Checked 2026-10-11.
- Products are exported from System, Data Transfer, Export as CSV, running in the background through a queue that needs cron.
- Adobe Commerce documentation: Import configurable products Checked 2026-10-11.
- In a product export, configurable products appear as one row plus a row for each simple-product variation, linked by a configurable variations column.