Job magento-catalogue-changes-not-showing-indexers-cron · revised 11 October 2026
Fix Magento product, price or stock changes that do not appear on the storefront
On a copy of your Magento store, an edit to a test product shows on the storefront within an agreed time, and the indexer settings and scheduled jobs behind it are documented.
You might be seeing
- A price change in the admin does not appear on the product page
- Stock shows in the admin but the storefront says out of stock
- New products do not appear in categories or search
- Changes only appear after someone runs a manual reindex
No passwords, keys, card details or admin invites needed to start.
What usually happened
Magento builds what shoppers see from index tables. When indexers are set to update by schedule, a background job must keep running to apply each change; if that job is not running, keeps failing, or the database triggers that record changes are missing, edits queue up in change-log tables and the storefront stays stale while the admin looks correct.
Who it’s for: Owner or manager of a Magento 2 or Adobe Commerce store whose admin edits to products, prices or stock take a long time to show, or never show, on the storefront.
Usually starts when: You changed a price, stock level or product and the site still shows the old data hours or days later, or products have gone missing from category pages.
The result: On a copy of your store, an edit to a test product appears on the storefront within the agreed time, every indexer is in the agreed mode and status, and the scheduled job that keeps them current is shown completing.
Check whether this job fits
Five questions, about two minutes. Your answers stay on this page unless you choose to email them.
Checks you can run yourself
Ask for the indexer status
Ask your host or developer to run the indexer status command on staging and send the redacted output.
Look for: Any indexer marked invalid or suspended, and the length of any backlog.
Ask for the job history
Ask for the most recent runs of the indexing job from the scheduled jobs table, status only.
Look for: Runs that stay pending or end in an error, or no run at all in the last hour.
What you get
- A table of indexers with mode and status before and after
- A note naming why edits were not showing, with redacted command and job evidence
- The corrected indexer modes and the scheduled-job change your host must make
- A test record: test edit, time made, time visible on the storefront
- Steps to apply the changes to the live store, including maintenance mode, and to undo them
Included
- The status and update mode of each indexer, and whether any are suspended or invalid
- The scheduled jobs that apply index changes: whether they run, finish and succeed
- The change-log tables and the database triggers that feed them
- A test product edit followed to the storefront, with the corrected settings or schedule written down
Not included
- Search engine, caching layer or content delivery network faults, beyond ruling them out
- Slow storefront performance and server sizing
- Extension code that writes data incorrectly
- Repairing wrong product data that was entered in the admin
- Upgrading Magento or Adobe Commerce
How we know it’s done
Agreed with you before work starts. Each check produces evidence you keep.
Every indexer on staging is in the agreed update mode and none is invalid or suspended
Evidence: Redacted indexer status output
The scheduled job that applies index changes shows recent runs that completed successfully, with none stuck pending
Evidence: Status counts from the scheduled jobs table for the last agreed period
A test product price edit on staging appears on its storefront page within the agreed time
Evidence: Edit time, storefront screenshot and the time it appeared
A test stock change appears in a category listing within the agreed time
Evidence: Screenshots before and after with times
Sign-off. You review the evidence and the staging test and sign off before payment. Applying the change on live, in a maintenance window, is a separate step your host takes.
If it fails. If the checks do not pass, you do not pay, and we hand over what we found so anyone can continue.
When it fits, and when we stop
It fits when
- The store runs Magento Open Source or Adobe Commerce 2.4 with command-line access available on the copy
- A staging copy exists, or your host can make one
- You or your host can run read-only status commands on the copy and send back the output, or give controlled shell access to the copy
- Someone authorised can apply the change to the live store, including a short maintenance window
We stop and tell you if
- The data is wrong in the admin as well, so reindexing would not help
- The scheduled jobs cannot be changed by you or your host
- The staging copy cannot reproduce the fault because it has little data
- A full-page cache or content delivery network is the cause and its configuration is not available to us
What could go wrong
Each mode and schedule is recorded as it was, so your host can put the previous values back, and a database backup is taken before the live change. We do not change the live database.
Scroll the table sideways to read it all.
| Risk | How we handle it |
|---|---|
| Switching indexer mode on a busy store causes database locks | The steps put the store in maintenance mode and pause scheduled jobs first, as Adobe's documentation advises. |
| A full reindex of a large catalogue takes long and slows the site | We estimate duration on the copy and schedule the live run for a quiet period. |
| Marking an indexer valid without checking leaves stale data in place | We confirm the data is indexed before changing any status and record the check. |
A second reviewer checks that the staging work could not affect live data, that the maintenance and cron steps are in the right order and that your host can reverse the change.
How we deliver
We arrange the work and independent review, then show you the result against the agreed checks. You keep authority over your systems.
- Confirm the staging copy matches live versions and has realistic data, with email and external feeds off
- Record indexer modes and status and the recent history of the index job
- Find the cause: job not running, job failing, change-log backlog, missing triggers or a suspended indexer
- Correct it on staging: recreate triggers by switching the mode and back, and fix the schedule, in maintenance mode
- Make a test product edit and record when it appears on the storefront
- Independent review, then hand over the evidence and steps; your host applies them live in a maintenance window
This is a one-off job, not emergency cover or a subscription. We confirm eligibility, the total price, a start window and a delivery date before you accept. Work starts only after agreed inputs, secure access, any licences and necessary permissions are in place. Platform, app and supplier charges are excluded unless the written quote includes them. No charge or booking is created by an enquiry.
Need to keep it working?
Discuss a recurring indexer and scheduled-job health check as a separate agreement.
Ongoing work is separately scoped and quoted: no monitoring, response-time guarantee or automatic subscription is included in this job.
Explore an ongoing engineering lane, or mention the responsibility you need in your enquiry.
What you can check
This is a new service. We have not delivered this job for a client yet.
Other ways to get this done
- Adobe documents the indexer commands and says a recurring job is needed to keep scheduled indexers current. Ask your host to confirm that job is running before anything else.
- If a manual reindex fixes the lag, running one as a stop-gap during a quiet period buys time while the cause is found.
Questions
Do you need access to my live Magento server?
No. We work on a staging copy, and your host or developer runs any command on live.
Why does a manual reindex only help for a while?
A manual reindex runs once. If the recurring job is not keeping up, the same lag returns, which is what we trace.
Will the fix work on every Magento version?
We state the version we test against. Behaviour such as the customer grid indexer differs between 2.4 releases, and we say where it matters.
Send an enquiry
Send us
- What changed and where it fails to show: price, stock, product or category
- How long the storefront lags, and whether a manual reindex fixes it
- The Magento or Adobe Commerce version and host type, if known
- Whether indexers are set to update on save or on schedule
- Whether anything changed recently: upgrade, migration, host move or extension
Later, once you agree
- A staging copy and the output of read-only status commands, or controlled shell access to the copy
- Redacted results of a query on the scheduled jobs table for the indexing job
- Your host's agreement to the schedule and maintenance window we specify
- A company-controlled secure handoff agreed before access: no live passwords, keys, private code or customer records by ordinary email.
You keep the live store, hosting account and database. We work on a staging copy and never on the live database; you or your host apply any indexer or schedule change on live.
Email fallback: open your mail app
If website submission is unavailable, review and send the fallback email yourself. An email fallback is not a website receipt. Or write to hello@syntheticindustry.ai with “magento-catalogue-changes-not-showing-indexers-cron” as the subject.