How Algolia reindexing works in Magento 2.4.7, and why it stalls

A merchandiser changes a product price, saves it, and checks the storefront. The product page shows the new price, but search results and category listings served by Algolia still show the old one. An hour later they still do. Someone runs bin/magento indexer:reindex and nothing obvious changes, or the run takes far longer than expected and the store slows while it does. The technical lead is left with a fair question, asked often on Magento Stack Exchange: how does a complete Algolia reindex work in Magento 2.4.7, and does the native reindex even line up with it?

It does not line up the way most people assume. Since Algolia's Magento extension 3.18.0, full reindexing is meant to go through the extension's own commands, not Magento's indexer framework. Get that wrong and most of the confusion that follows makes sense.

Two indexing systems share the same entities

Magento has its own indexer framework. Each indexer has a mode, either Update on Save or Update by Schedule, and is driven by bin/magento indexer:reindex, by cron, or by entity save events. The Algolia extension registers its own indexers in that framework, which is why they appear in bin/magento indexer:status next to catalog_product_price, cataloginventory_stock and the rest.

The extension's 3.18 documentation describes the change directly:

Since version 3.18.0, the following Magento indexers are disabled for full indexing. The extension will continue to rely on them for reindexing specific entities with Magento materialized views or entity save events if you do so. If you want to perform full reindexing, we highly suggest to keep this configuration disabled and run the newly created CLI commands instead.

In practice that means:

• Partial reindexing (one product, one category, one CMS page) still goes through Magento's indexers. A save event under Update on Save, or a materialized view changelog entry under Update by Schedule, tells the Algolia indexer which entity IDs changed, and those IDs get pushed to Algolia.
• Full reindexing through bin/magento indexer:reindex is switched off for the Algolia indexers by default. The extension adds dedicated CLI commands for a full rebuild. The exact names vary by release, so list the ones your installed version provides:

bin/magento list | grep -i algolia

If your deploy script or runbook still runs bin/magento indexer:reindex and expects Algolia to be fully rebuilt afterwards, on 3.18.x it won't be. The native indexers will run and the Algolia indexes will be left as they were. There is a configuration option to turn the old behaviour back on. Algolia recommends leaving it off, and we agree: a full catalog push to a remote API does not belong in a generic indexer run that also rebuilds price and stock.

Update on Save and Update by Schedule change who carries the load

The Magento indexer mode decides when the partial path runs.

With Update on Save, the Algolia indexer is triggered inside the save request. An admin user saving a product, or an import touching thousands of SKUs, causes Algolia work in the same process. On a small catalog that is fine. On a large one it makes admin saves slow and makes bulk imports fragile.

With Update by Schedule, Magento writes changed IDs to changelog (_cl) tables through database triggers. The indexer_update_all_views cron job, in the index cron group, later reads those changelogs and calls each indexer with the batch of changed IDs. The Algolia indexers get their IDs the same way as every other indexer.

On any catalog of meaningful size, use Update by Schedule. It moves the work out of the request, batches it, and gives you a changelog you can inspect when something goes missing:

bin/magento indexer:show-mode
bin/magento indexer:set-mode schedule

The indexing queue adds a second asynchronous hop

The extension can also use its own indexing queue, enabled in its admin configuration. With the queue on, the indexer does not call Algolia directly. It writes jobs to a queue table, and a separate cron-driven runner works through them in batches and makes the API calls.

So with Update by Schedule and the queue both on, a single product save goes through these steps:

1. The save writes to the database, and a trigger records the ID in the changelog.
2. indexer_update_all_views runs on cron and the Algolia indexer receives the ID.
3. The indexer writes a job to the Algolia queue table.
4. The queue runner, also on cron, picks up the job and sends the record to Algolia.

Each step is asynchronous and each can stall on its own. That is the right design for a busy store, but it means "search is out of date" can have four different causes.

Tracing a change that never reached search

Work through the chain in order. Don't start by running a full reindex, because that hides the cause.

Is cron running at all? Check cron_schedule for recent rows in success status, and for rows stuck in running or failing with error:

SELECT job_code, status, scheduled_at, executed_at, messages
FROM cron_schedule
WHERE job_code LIKE '%index%' OR job_code LIKE '%algolia%'
ORDER BY scheduled_at DESC LIMIT 50;

A job left in running after a killed PHP process can block that job from running again. If the index group runs as a separate consumer, confirm that consumer is actually up.

Did the changelog advance? bin/magento indexer:status on 2.4.7 shows the schedule status and the backlog count for each indexer in schedule mode. A backlog that keeps growing on the Algolia indexers means indexer_update_all_views is not keeping up or is not running.

Is the queue draining? Find the extension's tables with SHOW TABLES LIKE '%algolia%'; and look at the queue table: how many rows, how old the oldest one is, and whether any jobs show retry or error counts. Old rows that keep being retried usually mean the record is rejected: it is too large for the Algolia plan's record size limit, the payload is malformed, or the API key lacks the needed permissions.

What does the log say? The extension logs its API failures. Read them and var/log/exception.log before changing anything.

Configuring it so it does not stall or overload the store

• Put the Magento indexers in Update by Schedule mode, and confirm that the index cron group actually runs.
• Turn the Algolia indexing queue on for anything beyond a small catalog. Tune the number of jobs per run so that one cron run finishes well before the next one starts.
• Take full Algolia reindexes out of generic indexer:reindex runs. Run the extension's own commands on purpose: after a catalog import, after changing searchable attributes or index settings, and at a low-traffic time.
• Shrink records before you scale infrastructure. Indexing every attribute as searchable, or including large descriptions, makes each push slower and makes size-limit rejections more likely.
• Monitor the queue's depth and the age of its oldest row, not just whether cron is running. A queue that never empties is the earliest sign of a stall.

What to do next

Run bin/magento list | grep -i algolia and bin/magento indexer:show-mode on production today, and compare the output with your deploy scripts and runbooks. If anything still assumes indexer:reindex rebuilds Algolia, change it to the extension's CLI commands. Then add an alert on queue depth.

If search drift keeps coming back after that, the cause is usually somewhere else in the indexing and cron setup, and we cover that kind of operational work under Magento 2 services. If you want someone to trace it on your store, get in touch.