Magento 2 indexer stuck?
Diagnose the cause before resetting.

The short answer: do not reset a status you have not explained

When a Magento 2 indexer appears stuck, identify its ID and mode, compare timestamped observations, then establish whether the worker is still active. Inspect the correlated error and downstream dependency before planning a targeted reset or reindex.

Resetting an indexer changes its recorded state; it does not fix a failing query, unavailable search service or insufficient memory. If a worker is still processing, a second intervention can create competing work. If the displayed data is stale despite a ready index, the next investigation may be cache or shopper context.

This guide focuses on indexing. For the surrounding systems, use the Magento 2 health checklist and our cron troubleshooting guide.

Observe / Baseline

1. Identify the affected indexer and business symptom

date -u
php bin/magento --version
php bin/magento indexer:info
php bin/magento indexer:status
php bin/magento indexer:show-mode

Record the exact ID, status, mode and observation time. Confirm that the Admin and shell point at the same environment. Begin with a known product or action rather than treating every indexer as suspect.

These symptoms can have non-indexing causes. For example, a price rule or customer-group difference can explain a displayed price without any stuck process. Verify the expected result before deciding which index needs recovery.

2. Separate indexer state, scheduled progress and shopper outcome

Treat these as three observations. The overall indexer status does not replace evidence of incremental progress, and neither observation alone proves the shopper sees the correct result.

The Admin’s System → Tools → Index Management screen is a useful overview. Compare it with CLI evidence and the actual shopper context, especially if the screen has not been refreshed.

Observe / Two snapshots

3. Check whether processing is advancing

Take an initial snapshot, then repeat after a meaningful interval for this workload. Record normal import volume and expected processing time. A busy catalog can add changes faster than a healthy worker consumes them.

SELECT indexer_id, status, updated
FROM indexer_state
WHERE indexer_id = 'catalog_product_price';

SELECT view_id, mode, status, updated, version_id
FROM mview_state
WHERE view_id = 'catalog_product_price';

The indexer and materialized-view IDs can differ for custom implementations. Confirm the mapping in that module’s configuration; do not infer it from similar names. The updated column is not a guaranteed worker heartbeat. Raw state tables are supporting evidence, particularly when application locking is configured.

For a confirmed scheduled price view, inspect the newest changelog entry without counting the whole table:

SELECT version_id AS newest_change_version
FROM catalog_product_price_cl
ORDER BY version_id DESC
LIMIT 1;

Compare the view’s processed checkpoint with successive observations. If it advances, work is being recorded as processed. If the newest change ID keeps advancing faster, incoming work may be outpacing processing. A static checkpoint during an idle period is not a failure.

Do not treat an ID difference as an exact product backlog. IDs can have gaps; changes can reference the same entity; cleanup and concurrent writes affect the snapshot. An empty or missing changelog also needs context: confirm the view, mode, prefix and cleanup behavior.

Do not “catch up” by manually advancing mview_state.version_id or truncating changelog tables. That can discard unprocessed evidence and leave derived data inconsistent.

4. Correlate workers, errors and dependencies

# Linux example; rg requires ripgrep.
ps -eo pid,ppid,user,etime,args | rg "[b]in/magento (indexer:reindex|cron:run)"
tail -n 100 var/log/exception.log
tail -n 100 var/log/cron.log
df -h .
df -i .

Use the host’s process viewer if ripgrep is unavailable. Look at the actual process tree and hosting supervisor; scheduled jobs can run in child processes. In a cluster, check other nodes and any dedicated worker host. Absence from one filtered list does not establish that no worker exists.

Then correlate the affected indexer and time window with resource or dependency evidence:

• Database: ask the operator to inspect active waits, long transactions and deadlocks. A waiting query can look like idle PHP.
• PHP and host: check process termination, out-of-memory events, container limits and exhausted disk or inodes. CLI limits can differ from web PHP.
• Search: for search indexing failures, inspect engine connectivity, authentication and service health. Do not expose private endpoints or credentials.
• Deployment and extensions: match the first failure with release changes, missing classes or a custom indexer exception.

Capture a sanitized error signature and observation time. A working row left after termination and a genuinely active worker require different recovery plans. Do not kill every PHP process to make the status change.

5. Confirm the scheduled processing path

A full manual reindex may restore current output while the background path stays broken. For scheduled indexes, inspect the relevant cron jobs and recurring errors. Our bounded cron queries show how to compare due work with completed executions.

For advanced investigation, check the confirmed view subscription, trigger creation and module configuration. Use the Mview documentation and source matching the installed release. Do not run a generic “repair every trigger” recipe on an unknown schema.

Update on Save and Update by Schedule have different processing paths. A mode change is a maintenance operation, not an observational check. Adobe requires maintenance mode and disabled cron before switching indexer modes; plan restoration of both and verify normal processing afterward.

Illustrative evidence

Worked example: the backlog grows while the worker progresses

This simulated timeline describes a scheduled view, not a real customer incident. The numbers are illustrative checkpoints, not counts of products.

Time    Processed checkpoint    Newest change version
14:00   12000                   12600
14:05   12300                   13200
14:10   12800                   13500

Evidence: the processed checkpoint advances at every observation. The incoming change position advances too. The widening difference in the first interval does not by itself prove a dead worker.

Next investigation: compare import throughput, database waits and the business result. If ingestion slows but the checkpoint still advances and expected catalog changes arrive, investigate capacity rather than assuming interrupted execution.

Different branch: if the checkpoint stays fixed during sustained due work, correlate worker state and errors. A terminated worker with a stale status calls for a different runbook from a live process waiting on a database transaction.

Prove recovery through the next catalog change

1. Capture the post-recovery status, mode and checkpoint using the same observations.
2. Confirm the affected error stops recurring over an appropriate workload window.
3. Observe a planned catalog update through the normal save/import path, preferably on staging first.
4. Confirm scheduled processing advances without repeated manual intervention.
5. Check the intended shopper outcome in the same website, store view, currency and customer context.
6. Record the operator, cause, fix and next review in the store-health handoff checklist.

If the indexed result is correct but an anonymous product page is still old, investigate application rendering, full-page cache and the CDN. Broad cache flushing is not proof of an indexer fix.

Monitor progress, not just the status label

Watch processing age, recurring failures, import rate and expected catalog freshness. Define what “too long” means for this store rather than using a universal timeout. Check after PHP upgrades, release switches and import changes.

Review application-lock configuration with the operator against the installed release; Adobe documents its role in reporting failed runs more accurately. Do not publish the complete app/etc/env.php file when discussing that setting.

Buildmerce Health Guard includes indexer status monitoring, with scheduled monitoring and alerts described for Pro. Verify current edition and configuration. Do not assume status monitoring independently proves throughput, search correctness or the shopper’s price.

Common questions

Sources & revision notes

• Adobe: indexer CLI commands and prerequisites
• Adobe: Admin Index Management
• Adobe: indexing architecture, Mview and application locking
• Adobe: indexer configuration best practices
• Magento 2.4.8 source: indexer_state and mview_state schema; compare your installed release

October 29, 2026 · First edition. Added diagnostic snapshots, worker checks, scoped recovery examples and an interactive prerequisite checklist. Examples are illustrative; commands have not been runtime-tested across every supported release.

Continue with cron troubleshooting, the full Magento health check, or all Magento guides. Send a correction if a release-specific behavior needs clarification.