Magento 2 Indexer Stuck in Processing or Invalid: Diagnostic Guide

Problem and useful takeaway

One or more Magento 2 indexers remain stuck in Processing or Invalid status long after reindex runs. Catalog prices, stock, or search results can appear stale on the storefront even after product changes are saved. The useful takeaway: most stuck indexers are caused by a stale lock row in the indexer_state table or by a cron group that is not executing scheduled index jobs, and both conditions can be checked without restarting the web server.

Recognizable condition

You are likely dealing with a stuck indexer when:

• Admin panel > System > Index Management shows Processing or Invalid for an indexer such as Catalog Product Price, Catalog Search, or Stock.
• bin/magento indexer:status reports Busy, Working, or another non-Ready state for the same indexer code.
• Frontend pages show outdated prices, stock status, or search results despite recent product updates.

Cause and diagnostic table

Observation	Likely cause
Indexer status stays Processing after reindex completes	Stale lock row in indexer_state; the previous process crashed without releasing the lock
Indexer never leaves Invalid, and no reindex jobs appear in cron	Cron group index is not configured or the cron service is not running
Reindex starts then stops with an exception	Third-party module observer or plugin throws during indexer execution
All indexers hang simultaneously under load	Database lock contention or a long-running transaction blocking indexer updates

Terms used above: indexer_state is the database table that tracks each indexer's current status and lock state. A cron group is a named schedule that determines how often Magento runs a set of background jobs. MView is Magento's mechanism for tracking changes that need to be reindexed.

Ordered checks

1. Confirm which indexers are stuck

Run from the Magento application root directory as the file system owner, typically the user that owns var/ and pub/:

cd /var/www/html/magento
bin/magento indexer:status

Expected check: note every indexer_code whose status is not Ready or Update on Save. Common codes include catalog_product_price, catalogsearch_fulltext, and cataloginventory_stock. Risk: none; this is a read-only command.

2. Inspect logs for reindex errors

tail -n 100 var/log/exception.log
tail -n 100 var/log/system.log

Expected check: look for exceptions mentioning indexer class names, MView update failures, or third-party module namespaces around the time the indexer became stuck.

3. Query indexer_state for stale locks

Access the Magento database with a database user that has SELECT privileges. Take a database backup before any write operation.

SELECT indexer_code, status, updated_at
FROM indexer_state
WHERE status = 1
ORDER BY updated_at DESC;

Expected check: status = 1 means Working or Processing. If updated_at is older than the current reindex attempt, the lock is likely stale. Risk: this read-only query carries no risk; do not truncate or update the table without a backup.

4. Verify cron is executing indexer jobs

SELECT job_code, status, executed_at
FROM cron_schedule
WHERE job_code LIKE '%indexer%'
ORDER BY executed_at DESC
LIMIT 20;

Expected check: recent success entries for jobs such as indexer_reindex_all_invalid or indexer_update_all_views. Missing entries or only error entries indicate cron is not running or the index cron group is misconfigured.

5. Check file ownership and writable directories

Ensure the Magento file system owner can write to var/, pub/, and generated/. Permission failures can prevent indexer state updates from being written.

Fixes tied to findings

If a stale lock row is found

Reset only the affected indexer codes:

bin/magento indexer:reset [indexer_code]
bin/magento indexer:reindex [indexer_code]

Replace [indexer_code] with the actual code from step 1, for example catalog_product_price. Required permissions: file system owner. Expected check: run bin/magento indexer:status afterward; the indexer should show Ready or Update on Save. Risk: running a full reindex during peak traffic can increase database load and slow checkout; schedule during a maintenance window.

If CLI reset does not work, clear the lock directly in the database:

UPDATE indexer_state
SET status = 0
WHERE indexer_code = '[indexer_code]' AND status = 1;

Required permissions: database user with UPDATE privileges. Risk: updating the wrong rows can corrupt index metadata. Restore from the pre-change database backup if an incorrect row is modified. Afterward, run the reindex command above to repopulate index data.

If cron is not running indexer jobs

Confirm the system crontab exists for the Magento file system owner:

crontab -u [magento_file_system_owner] -l

Expected output should include Magento's bin/magento cron:run entries scheduled every minute. If missing, reinstall the crontab per the installation documentation for your edition. Then restart the cron service, for example:

sudo systemctl restart crond

Wait several minutes, then repeat the cron_schedule query from check 4.

If a third-party module throws during reindex

Disable recently installed modules one at a time, then reindex:

bin/magento module:disable [Vendor_ModuleName]
bin/magento indexer:reindex [indexer_code]

Expected check: if reindex succeeds after disabling a module, contact the module vendor or patch the observer that throws during MView update.

If database contention is observed

Review database process lists during reindex for long-running transactions. Increasing innodb_lock_wait_timeout may help, but this is a database configuration change outside Magento code and should be made by a database administrator during a maintenance window.

Escalation criteria

• The indexer returns to Processing immediately after reset, suggesting a code-level exception rather than a stale lock.
• Reindex fails on all indexers, suggesting environment or database corruption.
• The issue recurs on a production schedule; engage Magento Support for Adobe Commerce or a certified Magento developer for Open Source.

Verification

• Run bin/magento indexer:status; all previously stuck indexers should show Ready or Update on Save.
• Query indexer_state WHERE status = 1; no rows should remain for the previously stuck indexer_code.
• Confirm cron_schedule contains successful indexer_reindex_all_invalid or related entries after cron runs.

Limitations and version assumptions

This guide assumes Magento 2.4.x. Magento 2.3 handles some indexers differently, and Adobe Commerce may include additional scheduled index behaviors not present in Open Source. Table names and CLI behavior can vary by edition. Do not truncate indexer_state on production without a backup. If any step produces unexpected output, stop and have the result reviewed by a developer with access to your environment.