A saved product is only one stage
Commerce platforms often maintain derived structures so the storefront can answer catalog queries efficiently. A product change can be present in the primary data while the storefront's searchable or precomputed representation still reflects an earlier state. Repeatedly flushing response caches does not necessarily rebuild the missing derived data.
In Magento and Adobe Commerce, indexers transform source data into structures used by the application. Their modes and dependencies matter. This guide focuses on scheduled indexing and stale catalog evidence, not customer-private cache separation. Check the exact Commerce version and extensions before using a command or interpreting an indexer's state.
Setup: establish the freshness chain
Choose a synthetic product or an approved low-risk catalog change. Record its website, store view, attribute scope and expected storefront result. Identify the relevant indexer using the installed platform's tools rather than guessing from the visible symptom. Document whether it operates on save or by schedule, and who owns the scheduled runner.
Adobe's indexing documentation distinguishes immediate update behavior from scheduled cron-driven work. It also documents version-specific differences, including customer-grid behavior around 2.4.8. Do not apply a mode recommendation universally. Capture scheduler execution, indexer state and database health without changing them first; the state before repair is part of the incident evidence.
Illustrative incident: the price changed only in Admin
An illustrative store imports a price change. The administrative value is correct, but a storefront still shows the old price. Operators flush caches several times, briefly increasing load, while the relevant scheduled indexing work remains delayed. This teaching scenario is not a claimed customer incident or a measured optimization result.
Trace one product through its source value, relevant derived data and delivered page. Include the website and customer-group context where they affect the price. Do not compare different store views and conclude that indexing failed merely because their valid scoped values differ.
Troubleshooting: separate data, indexing and delivery
| Observation | Collect | Next boundary |
|---|---|---|
| Saved source value is wrong | Import outcome and scoped attribute value | Correct the write before rebuilding anything |
| Source is current, derived view is old | Indexer mode, status and scheduled executions | Investigate delayed or failed index work |
| Index is current, storefront is old | Origin response and cache provenance | Review response caching separately |
| Reindex repeatedly fails | First error, database resources and extension changes | Repair the cause before retrying |
Cron appearing in a process list does not prove that the intended indexing work completed. Look for successful execution evidence and the specific catalog outcome. Likewise, an indexer status label is useful context, not a replacement for checking the actual product representation.
Corrective action and workload control
Repair the scheduler, permissions, dependency or application defect identified by evidence. If a targeted reindex is appropriate, choose the relevant indexer and an approved operating window. A full reindex can impose substantial database and application load; do not launch several overlapping rebuilds because the first command appears slow.
Avoid deleting change-log data or resetting indexer state as a generic troubleshooting shortcut. Such operations can destroy the evidence needed to understand missing work and may require a supported recovery plan. Use documentation for the installed version and involve the platform owner when extensions alter indexing behavior. Review cache invalidation only after the derived catalog is correct.
Verification, freshness SLO and SOP
Verify the chosen product from the intended store view and purchasing context. Test a second catalog change after recovery to prove that the normal scheduled path works, rather than only the one-off repair. Observe scheduler progress and database load over the expected operating interval. Check that no import or indexing job remains accidentally disabled.
An internal catalog-freshness SLO measures time from an accepted change to the verified storefront representation. It is distinct from uptime and must state the applicable catalog operations. A commercial SLA needs separately agreed terms. The SOP should identify the indexer owner, scheduler evidence, safe rebuild window, escalation conditions and rollback procedure for the triggering import or extension release.
See Magento engineering and database administration for coordinated storefront and persistence support.
Technical reference
Adobe Commerce indexing components, reviewed 19 October 2026. Review version notes before changing indexer modes.