The Catalog Price Rule Indexer in Depth: How Automatic Discounts Get Calculated

1. Index versus runtime: the fundamental difference from cart price rules

Cart price rules, meaning cart level discount rules with or without a coupon code, get evaluated live on every cart calculation: the Validator checks every active rule's conditions against the current cart contents and applies matching actions in real time. That is feasible because a cart is inherently small, usually a handful to a few dozen line items, so rule evaluation per request stays manageable.

Catalog price rules, on the other hand, potentially affect the entire product catalog at once, visible on every category page, every product page, and every price filter in layered navigation. A live evaluation of every active rule against every single displayed product on every page view simply would not be performant enough with thousands of products, which is why Magento deliberately relies on precomputation instead of runtime evaluation here.

2. How the catalogrule_rule indexer works

The indexer with the ID catalogrule_rule iterates over every active catalog price rule and determines the matching products through its conditions, such as category membership or attribute values. For every combination of product, customer group, website, and validity period, the indexer calculates the resulting rule price and writes the result into the catalogrule_product_price table, tagged with a validity window during which the computed price stays unchanged.

If nothing changes about the involved products or conditions within a rule's validity window, the precomputed window stays represented as a single row. If instead, say, the discount percentage changes on a certain date through a second, time shifted rule on the same product, several rows with their own validity windows get created, meaning the row count in catalogrule_product_price grows with the number of time staggered rule changes per product.

# Check status and mode of the catalog rule indexer
bin/magento indexer:status catalogrule_rule
bin/magento indexer:show-mode catalogrule_rule

3. How price display consumes the precomputed rule prices

The actual price display does not read catalogrule_product_price directly, it goes through the catalog_product_price price indexer, which, while building the final price index tables catalog_product_index_price, factors in the precomputed rule prices for the current date and compares them against regular prices and any special prices to determine the lowest price to display.

This chaining of two indexers means in practice that a newly created or changed catalog price rule only actually becomes visible on the storefront after a full run of catalogrule_rule followed by catalog_product_price. If only one of the two indexers runs, the catalog keeps showing the old prices despite correctly computed rule prices, a common source of confusion when debugging a rule change.

4. Performance issues with many active rules on a large catalog

Runtime of the catalogrule_rule indexer does not grow linearly, it grows combinatorially: every additional active rule multiplies against the number of matched products, the number of customer groups, the number of websites, and the number of time based validity segments. On a catalog with tens of thousands of products and a double digit number of simultaneously active, overlapping rules, a full reindex run can take noticeably long and generate significant database load along the way.

Rules with unlimited or far future reaching validity periods are especially costly, since they needlessly inflate the calculation of time segments, as are broadly scoped conditions that effectively match nearly the entire catalog instead of a clearly bounded product set. Regularly reviewing expired or no longer needed rules that were simply disabled out of convenience instead of deleted noticeably reduces indexer load, since disabled rules are not recalculated but their historical rows still get carried along in the table.

5. Choosing the reindex mode strategically: schedule versus save

In Update on Save mode, a full reindex fires immediately on every rule change, which leads to noticeable admin wait times with frequent rule changes, because the save operation blocks until the indexer finishes. For stores with frequently changing campaigns, Update by Schedule is considerably more forgiving, since the actual recalculation runs asynchronously through the indexer_reindex_all_invalid cron job or the mview changelog processing.

It matters to tune the cron cadence realistically against the actual frequency of rule changes: a reindex cron running too rarely means new discount campaigns appear on the storefront late, while a cron running too frequently ties up system resources needlessly when nothing changed about the rules between two runs at all.

# Switch the catalog rule indexer to schedule mode explicitly
bin/magento indexer:set-mode schedule catalogrule_rule catalog_product_price

6. Targeted reindex strategies instead of a blanket full reindex

Instead of reflexively triggering a full reindex across the entire catalog on every small rule change, it pays off to deliberately separate rules that genuinely affect the whole catalog, such as a site wide discount campaign, from rules that only match a clearly bounded product set, such as a single category. For the latter, deliberately tight conditions keep the rule's match count small, which directly reduces the indexer's combinatorial load.

For planned campaigns with a known fixed start and end date, it is also worth creating the rule well ahead of the actual campaign start and letting the indexer run through a single full pass outside peak hours, rather than trusting the regular cron cadence during the actual campaign launch, when increased system load from higher traffic is already expected anyway.

7. Limits of partial reindexing for catalog price rules

Unlike the price indexer for regular product price changes, which uses mview changelogs to selectively pick up only affected products, the catalogrule_rule indexer effectively always recomputes fully per rule on a rule change: if a single rule changes, every product matched by that rule gets recalculated across its entire validity period, not just the products that actually changed since the last run.

That limitation cannot be worked around through configuration, only through a deliberate reduction of the rule's own scope: the smaller the product set matched by a single rule, the cheaper every recalculation of that rule turns out. For rules that already touch nearly the entire catalog, the only realistic option is often to deliberately batch their changes and apply them outside main business hours, rather than making several small adjustments spread throughout the day.

8. Monitoring indexer runtime and catching bottlenecks early

Sensible monitoring tracks the runtime of every catalogrule_rule run over time and raises an alert once a clear increase against the historical average shows up, because such an increase almost always points to a newly added, too broadly scoped rule or an unexpectedly grown product set, well before customers notice delayed price updates on the storefront.

Regularly checking the row count in catalogrule_product_price helps as well, since an unexpectedly sharp jump in that table usually correlates directly with a new rule whose conditions unintentionally reach much wider than actually intended, for instance through an accidentally too generic attribute condition.

9. Indexer building blocks at a glance

The table below summarizes the central building blocks of catalog price rule indexing along with their respective role.

10. Summary

11. FAQ: Catalog Price Rule Indexer: The Essentials at a Glance