Magento 2 Indexer Stuck on "Reindex Required"? Causes and Fixes

If your Magento 2 admin permanently shows "Reindex required" on one or more indexers — even right after cron has run, even right after you've manually reindexed — you're not imagining it. This is a documented behavior in Magento core, not a one-off misconfiguration on your store.

Why this matters beyond the annoying admin message

This isn't just a cosmetic admin panel issue. An indexer that's continuously re-triggered on every cron run — rather than only when the underlying data actually changed — creates ongoing, unnecessary database and CPU load. On a catalog of any real size, that shows up as elevated server load with no obvious single cause, because it's spread across every cron cycle rather than concentrated in one identifiable spike.

How to confirm this is what's happening on your store

1. Check indexer status: run bin/magento indexer:status from the Magento root. This lists every indexer's mode (Update by Schedule or Update on Save) and current status (Ready, Processing, or Invalid).
2. Check cron history: query the cron_schedule table for indexer_reindex_all_invalid job codes and look at how frequently they're actually firing versus how frequently they should be, based on your cron group configuration.
3. Watch the pattern across two or three cron cycles: if an indexer goes Invalid → Ready → Invalid again within a cycle or two, with no corresponding data change (product edit, category move, price update) that would legitimately invalidate it, that's the loop, not a one-off configuration issue.

What actually fixes it

The Magento core team's fix (tracked against issue #29478) applies the same logic the CLI indexer:reindex command uses to the cron job path, so both paths handle invalidation consistently. Depending on your Magento version, this may already be patched — check your version against the fix's target release before assuming you need a custom patch.

If you're on a version where this isn't patched, or you're running enough customizations that a core patch needs careful regression testing before deploying, the practical mitigations are:

• Switch the affected indexer to "Update on Save" if your catalog size tolerates it — this sidesteps the cron-specific behavior entirely, at the cost of slower individual save operations
• Audit third-party modules that hook into indexer invalidation — a module that invalidates an indexer more aggressively than necessary (e.g., on every save rather than only on relevant field changes) will reproduce loop-like symptoms even after the core bug is patched
• Apply the targeted core patch if you're on an affected, unpatched version and have the testing capacity to verify it against your specific customizations before production deployment

When this is actually a different problem

Not every stuck indexer is this specific loop. Large catalogs with genuinely long reindex times (tracked in Magento's issue #31285 and #26403) are a capacity/optimization problem, not a bug — the fix there is reindex strategy (partial vs full, schedule tuning) rather than a core patch. And indexers that fail outright with a PHP error in the log are a different class of problem entirely — check your exception log before assuming this specific loop is the cause.