Diagnosing Stuck Magento 2 Indexers: When 'Working' Means Stalled

Recognizable condition

Your Magento 2 admin shows one or more indexers stuck in Working for an abnormal amount of time, or Reindex required persists after cron should have cleared it. Storefront search and category pages omit recently added or changed products, price rules apply inconsistently, and URL rewrites behave unpredictably. In the database, cron_schedule has no recent successful indexer jobs, and var/log or var/report may contain lock wait timeout, process killed, or search engine connection errors.

Useful takeaway: before resetting an indexer, confirm that no live process or cron job currently owns it. Resetting an active reindex can produce duplicate or partial index writes.

Cause and diagnostic table

Observation	Likely cause	Diagnostic signal
cron_schedule idle; no cron process	OS or Magento cron stopped	crontab -l empty; ps aux shows no cron:run
indexer:status shows working; no matching process	Crashed indexer left stale state	indexer_state.updated_at is old; process list lacks a reindex query
Long-running transaction or lock wait	Database contention blocking indexer	information_schema.innodb_trx or SHOW PROCESSLIST shows waiting/locked rows
Search errors; cluster health not green	Elasticsearch/OpenSearch down or version mismatch	Cluster health returns red/yellow; Magento logs show search exceptions
Product saves very slow; backlog grows	Wrong indexer mode for the workload	UPDATE_ON_SAVE under load, or UPDATE_BY_SCHEDULE with unprocessed backlog

Ordered checks

1. Confirm OS cron and Magento cron group entries. Run on the server shell as the Magento file system owner (often the web server user or a dedicated magento user). Check the crontab and running processes:

   sudo -u <magento_user> crontab -l
   ps aux | grep -E 'cron|magento' | grep -v grep

   Expected: Magento cron entries for default, index, and other groups appear, and at least one cron process is running. Risk: running as root can create root-owned var/ files; use the same user that owns the Magento file system.

2. Inspect cron_schedule for stuck or failed indexer jobs. Run in a MySQL/MariaDB client connected to the Magento main database:

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

   Expected: recent successful rows for indexer jobs. Missing rows or repeated running/error status point to cron or job failure.

3. Compare indexer status with the database process list. Run the CLI from the Magento root directory as the file system owner:

   bin/magento indexer:status

   Then check the database for matching processes:

   SHOW FULL PROCESSLIST;

   Expected: if the status is working but no process and no recent cron job exist, the state is stale.

4. Check database locks and long transactions. Run in the database client:

   SELECT trx_id, trx_started, trx_mysql_thread_id, trx_query
   FROM information_schema.innodb_trx
   WHERE trx_started < DATE_SUB(NOW(), INTERVAL 5 MINUTE);

   Expected: no old transactions holding locks on indexer tables. Long transactions can block reindex writes.

5. Verify search engine cluster health and configuration. Check the cluster from a shell:

   curl -X GET "<search_host>:<search_port>/_cluster/health?pretty"

   Confirm the configured engine from the Magento root:

   bin/magento config:show catalog/search/engine

   Expected: cluster status green; configured engine matches the deployed service and a supported Magento version. Risk: do not swap or upgrade Elasticsearch/OpenSearch without validating compatibility.

6. Review logs for the failing indexer. Inspect var/log/, var/report/, and search engine logs. Look for entries naming the indexer and the failure mode, such as lock wait timeout, killed process, or search connection refused.

Fixes tied to findings

If cron is absent or broken

Reinstall the Magento cron entries for the file system owner, then run the index group once to verify it executes:

bin/magento cron:run --group=index

Confirm new cron_schedule rows appear and complete successfully.

If an indexer is stuck with no live process

Only after Check 3 confirms no matching process, reset that indexer state and reindex it in a controlled window:

bin/magento indexer:reset <indexer_name>
bin/magento indexer:reindex <indexer_name>

Risk: do not reset while a reindex is running. Avoid direct database edits to indexer_state unless the supported CLI cannot recover it.

If database contention is confirmed

If a specific transaction blocks the indexer and the database owner approves, terminate it from the database client using the thread ID observed in Check 4:

KILL <thread_id>;

Record the thread ID and query before killing, then rerun the reindex.

If the search engine is down or mismatched

Restore the search service before reindexing. If the configured engine does not match the running service, correct the configuration to a supported combination, then reindex catalogsearch_fulltext.

Escalation criteria

• Repeated deadlocks or lock wait timeouts after transaction cleanup.
• Reset and reindex complete successfully, but storefront data remains inconsistent.
• Search cluster stays degraded or cannot reach green status.
• Checkout or admin product save paths are impacted.
• You suspect data corruption or need Adobe or cloud platform support.

Limitations and verification

This guide assumes a Magento 2.4-style CLI with MySQL/MariaDB and Elasticsearch/OpenSearch catalog search. Indexer names, consumer behavior, split-database settings, and search engine requirements vary by version and patch level, so confirm commands and configuration against your deployed release.

On split-database or queue deployments, check the correct database and consumer group. A healthy checkout database does not prove the catalog database is healthy. Run large reindexes during low traffic or maintenance mode; Update on Save can make product saves slow under load.

Reproduce the issue in staging with the same cron schedule, indexer modes, and search engine configuration before changing production. Record bin/magento indexer:status and cron_schedule timestamps before and after the fix, and confirm stuck entries clear while new jobs succeed. Validate storefront category and search results after reindex, including a known recently changed product. Monitor the database process list and search cluster health during reindex to confirm no lock waits or indexing backlog remain.