Magento and Adobe Commerce ship a native Product Alerts module that emails registered customers when an out-of-stock item returns or its price drops below what they last saw. You enable it under Catalog configuration, set the run frequency, and a cron job sends the batch. The harder parts are Hyva rendering, guest capture, and deliverability.
Those alerts are some of the highest-intent email a store sends. Someone already wanted the product and told you so. This guide covers how the native feature actually works, where it falls short, how the subscribe form behaves on a Hyva storefront, and how to keep the emails out of spam folders. For context on how this fits a broader Magento build, see our Magento development services.
What Magento Product Alerts do out of the box
The Magento_ProductAlert module provides two independent alert types:
- Stock alert (“Notify me when this product is in stock”): a link on out-of-stock product pages that lets a logged-in customer subscribe. When the product’s salable quantity goes back above zero, the next alert cron run emails every subscriber.
- Price alert (“Notify me when the price drops”): a link that stores the current price against the customer. When the price later falls below that stored value, the customer gets an email.
Both are off by default. You turn them on under Stores > Configuration > Catalog > Catalog, in the Product Alerts section. The underlying config paths are catalog/productalert/allow_price and catalog/productalert/allow_stock, so they can be set per website scope if you run multiple storefronts.
Two behaviors surprise teams the first time:
- The stock alert link only appears when Display Out of Stock Products is set to Yes under the Stock Options section. If out-of-stock products are hidden, there is no page to put the link on, so the alert link never renders.
- Price alerts fire only when the current price is strictly below the price stored at subscription time. An equal or higher price sends nothing, and the subscription stays active until the drop happens.
The cron job that actually sends the emails
Enabling the alerts shows the links but sends nothing on its own. Delivery is handled by a cron job, catalog_product_alert, which runs in the product_alert cron group and defaults to a daily schedule. On each run it scans the subscription tables, finds products that now qualify, queues the emails, and marks the subscriptions as sent.
If alerts are not arriving, work through this order:
| Symptom | Likely cause | Where to check |
|---|---|---|
| No link on the product page | Alerts disabled, or out-of-stock products hidden | Catalog config, Stock Options |
| Link shows, no email ever sends | Cron not running | cron_schedule table, job_code catalog_product_alert |
| Emails queue but never leave | Mail transport or queue consumer down | Transactional email settings, SMTP relay |
| Some customers never notified | Price never dropped below their stored value | product_alert_price table |
You can force a run with bin/magento cron:run --group="product_alert" while debugging. The subscription data lives in two tables worth knowing: product_alert_stock (customer, product, website) and product_alert_price (customer, product, the stored price, website). If you ever need to audit who is waiting on a restock, those tables are the source of truth. The observers, cron model, and email logic are all readable in the Magento_ProductAlert module source, which is the fastest way to confirm exact behavior for your version, and MGT-Commerce’s product alerts walkthrough maps the config paths to the tables in one place.
The registered-customer limit, and why it matters
The native feature only works for logged-in customers. A guest browsing an out-of-stock product sees the link, clicks it, and is sent to log in or register before the subscription is saved. That login wall quietly kills most of the demand signal, because the people most likely to abandon are exactly the ones who will not create an account to get a restock email.
This is the single biggest reason stores replace or extend the native module. Lars Roettig’s walkthrough of enabling notify-me in Magento 2 is a good reference for how the native link is wired before you decide to extend it. The common fixes:
- A guest-capture extension that stores an email address against the product without requiring an account. Several Adobe Commerce Marketplace modules do this, and some add restock coupons or a one-click resubscribe.
- A marketing-platform integration (for example Klaviyo) that owns the back-in-stock flow, captures the email client-side, and sends through the platform rather than Magento. If you already run Klaviyo for the rest of your lifecycle email, keeping restock there centralizes reporting and deliverability.
Either way, decide early whether the alert email belongs in Magento or in your marketing platform, because splitting restock across both leads to duplicate sends.
Rendering the subscribe form on a Hyva storefront
On Luma, the alert link is a RequireJS and jQuery template. Hyva removes that stack, so the native template needs a Hyva-compatible version. Most of the back-in-stock modules that advertise Hyva support ship a companion module that swaps the Luma template for an Alpine.js and Tailwind equivalent. There are three details that separate a form that works from one that silently fails:
- Form key handling. Hyva exposes
hyva.getFormKey()so an inline Alpine component can attach a valid CSRF token to the POST. A form copied straight from a Luma module without this will be rejected. - Configurable product variants. On a configurable product, the subscribe needs the selected simple product’s SKU, not the parent. Well-built Hyva companions listen for a variant-change event (for example a custom
windowevent dispatched by the swatch renderer) and update the SKU the form submits. Skip this and every variant subscribes to the same SKU. - Private content and caching. The product page is served from full page cache, so anything customer-specific has to load through Hyva’s customer-data sections rather than being baked into the cached HTML. If you show “you are subscribed” state, it has to come from section data. Our guide to Magento customer data sections on Hyva explains why the mini-cart and any private UI go stale if you get this wrong.
Because the alert UI is small, it is tempting to hand-roll it. That is fine, as long as you treat it like any other Hyva component: inline Alpine, a real form key, and section data for per-customer state. This is the kind of frontend adaptation work our Hyva development services handle on migrations, where a dozen small Luma widgets each need a Hyva equivalent.
Throttling: do not send one email per product
A restock or a sitewide price change can match thousands of subscriptions at once. Two throttling concerns come up:
- Cron overlap. If a run takes longer than the interval, a second run can start and both touch the same rows, causing database locks. Keep the
product_alertcron group on a schedule longer than a typical run, and watch for overlapping executions. - Send-rate limits. Your sending domain and relay have per-hour limits. Dumping 50,000 restock emails into the queue in one minute is a fast way to get rate-limited or flagged. A relay that paces delivery, or a marketing platform that batches, protects your reputation.
Large subscription tables also slow the matching query. If the alert cron is crawling, confirm there are usable indexes on product_id and customer_id in the alert tables, and prune subscriptions that have already been sent.
Deliverability: the email has to actually land
An alert that lands in spam is worse than no alert, because the customer thinks you never told them. Restock and price-drop emails are transactional-adjacent, so they inherit all the normal authentication requirements:
- SPF, DKIM, and DMARC aligned to your sending domain.
- A dedicated or reputable relay, not the origin server’s local mail transport.
- A warmed sending domain if volume is new.
We cover the full setup in transactional email deliverability for Magento, and the same discipline that keeps order confirmations out of spam keeps alert emails landing. Treat the alert as part of the same sending reputation, not a separate afterthought. If you also run abandoned-cart email, coordinate the two so a customer who got a restock alert is not hit with a conflicting cart nudge minutes later; our guide to abandoned cart recovery on Magento and Hyva covers that timing.
How other platforms handle it
If you are weighing platforms, back-in-stock is a useful small test of how much a stack makes you reach for third-party apps:
| Platform | Native back-in-stock | Guest capture | Notes |
|---|---|---|---|
| Magento / Adobe Commerce | Yes, registered only | Needs extension | Full control, cron-driven, self-hosted sending |
| Shopify | App-based | Yes, via app | Mature app ecosystem, per-send pricing adds up at scale |
| BigCommerce | App or API | Via app | Similar app-led model |
| Shopware | Plugin | Via plugin | Store plugins cover it |
Teams running Shopify development, BigCommerce development, or Shopware development will lean on an app or plugin for this; on Magento the capability is in the core, and the work is extending it for guests and rendering it on Hyva. That trade, more control versus more setup, runs through most Magento feature decisions.
FAQ
Does Magento send back-in-stock emails without an extension?
Yes, for registered customers. The native Magento_ProductAlert module adds a “Notify me when this product is in stock” link to out-of-stock product pages, and the catalog_product_alert cron job emails subscribers when salable quantity returns. Guests cannot subscribe without an account unless you add an extension.
Why are my price drop alerts not sending?
The native price alert fires only when the current price is below the price stored when the customer subscribed. If the price is equal or higher, nothing sends and the subscription remains active. Also confirm the product_alert cron group is running and that your mail transport is delivering.
Do product alerts work on a Hyva theme?
The feature works, but the storefront link is a Luma RequireJS template that Hyva does not load. You need a Hyva-compatible version of the form, built with inline Alpine.js, the Hyva form key, and customer-data sections for per-customer state. Most Hyva-ready alert modules ship this companion.
How often does Magento check for restocks?
The catalog_product_alert cron job defaults to a daily schedule in the product_alert group. You can change the frequency in the cron configuration, but run it on an interval longer than a single run takes to avoid overlapping executions and database locks.
Should alerts send from Magento or from a marketing platform?
Either works, but not both. If you already run a platform like Klaviyo for lifecycle email, letting it own back-in-stock centralizes reporting and deliverability. If you keep alerts in Magento, treat them with the same SPF, DKIM, and DMARC discipline as order email.
Getting it right the first time
Back-in-stock and price-drop alerts are cheap to turn on and easy to get subtly wrong: the guest wall, the Hyva template gap, the cron that never runs, the emails that land in spam. Done properly, they recover demand you already earned. Bemeir is the USA’s first Hyva Gold Partner, and we build these flows as part of full Magento and Adobe Commerce storefronts. Learn more about Bemeir, browse our technology partners, or see what we do at Bemeir.
